AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 33 Bitcoin

Include payer nonce in payer metadata again

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

86/100 · Strong
Include payer nonce in payer metadata again

InvoiceRequest and Refund have payer metadata consisting of an
encrypted payment id and, originally, a nonce used to derive the payer
signing keys and authenticate any corresponding invoices. The nonce was
elided to save space once it was included in the OffersContext of
blinded reply paths, but that means verifying a Bolt12Invoice requires
state outside the invoice itself. Upcoming payment proofs (#4297) need
the invoice signing keys derivable from the invoice request alone, so
include the nonce in the payer metadata again and verify invoices using
it rather than the context's nonce.

This breaks verification of invoices for invoice requests and refunds
with blinded paths created by prior versions, as their payer metadata
lacks the nonce; such payments will fail and must be retried with a new
payment id. Refunds without blinded paths are unaffected, as their
metadata always included the nonce.

Co-Authored-By: Claude <noreply@anthropic.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how BOLT12 invoices are verified in the Lightning Dev Kit. Previously, some invoices could be verified using a nonce stored in the blinded reply path context. Now, the nonce is always included inside the encrypted payer metadata carried by the invoice request or refund. This makes invoices self-contained and prepares the code for future payment proofs. It is a protocol-correctness and forward-compatibility change, not a fix for an active exploit. Old invoice requests/refunds with blinded paths created before this change will fail verification and must be retried with a new payment id.

Recommended action

Treat this as a behavior-affecting protocol update rather than an urgent vulnerability patch. Nodes using BOLT12 offers/refunds with blinded paths should be prepared for failed invoice verification from counter-parties running older code and should retry with a fresh payment id. Review upcoming payment-proof work (#4297) for related security assumptions. No immediate exploit mitigation is required.

Security signals we found

01

BOLT12 invoice verification now depends only on data inside the invoice request/refund, reducing reliance on external context

02

Removes a verification path (verify_using_payer_data) that used reply-path context instead of invoice-contained metadata

03

Breaks backward compatibility for prior-version invoice requests/refunds with blinded paths, causing payment failures

04

Payer metadata now includes both encrypted payment id and nonce again

Risk score

Why this scored 33/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.