feat: support nodePubkeys invoice checks - #3
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements draft LUD-XX
nodePubkeyssupport for LNURL-paypayRequestresponses, aligned with the local proposal in/home/exedev/code/lud-proposals/lud-xx-node-pubkeys.mdand the open upstream spec PR: lnurl/luds#297.I verified the local proposal and PR #297 are byte-identical. The design is also materially stronger than older prior art like lnurl/luds#204 because it keeps the human Lightning Address unchanged and attaches structured invoice-origin metadata to the LUD-06 response.
What changed
payRequest.nodePubkeys:pubkeyntag when presentnis absentpayment.nodePubkeyVerificationfor BOLT11 instructions:status: "verified"with matched pubkeystatus: "mismatch"with non-blocking warning by defaultnodePubkeyPolicy:"warn"default — spec-compatible non-blocking warning result"enforce"— throwsNodePubkeyMismatchError"off"— skips nodePubkeys comparison while preserving other BOLT11 validationNodePubkeyNodePubkeyPolicyNodePubkeyVerificationBolt11PayeeNodeIdSourceNodePubkeyMismatchErrorexamples/basic/node-pubkeys.tsusing real signed test invoices.Verification
bun run check✅145 pass✅3 pass✅bun examples/basic/node-pubkeys.ts✅npm publish --dry-run✅Notes
This intentionally follows the LUD proposal's wallet UX: mismatches are surfaced but not blocked by default. Strict blocking is available only as an explicit caller policy.