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

Remove nonce from outbound payment OffersContexts

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

90/100 · Strong
Remove nonce from outbound payment OffersContexts

Now that the payer nonce is included in the payer metadata of
InvoiceRequest and Refund, Bolt12Invoice verification no longer needs
the nonce from the blinded path's OffersContext. Remove it from
OffersContext::OutboundPaymentForOffer and
OffersContext::OutboundPaymentForRefund, along with
enqueue_invoice_request's nonce parameter, which only existed to supply
it. The nonce in RetryableInvoiceRequest is no longer used either but
is still persisted -- and retained when reading state written by prior
versions -- so that such versions can retry the payment and verify the
resulting invoice after a downgrade.

The payment_id is kept in both variants, however. While no longer needed
to confirm the invoice is for an invoice request or refund we created,
it is checked against the payment id recovered from a received
Bolt12Invoice's payer metadata to ensure the invoice arrived over the
blinded path created for that payment. This prevents an attacker from
reusing the blinded path of one of our payments to deliver another
payment's invoice and correlate the two as ours.

Co-Authored-By: Claude <noreply@anthropic.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit removes an old cryptographic nonce from the data carried inside Lightning "blinded paths" used when sending BOLT 12 offers and refunds. The nonce is no longer needed because a newer "payer metadata" field already carries the same secret. The commit keeps the payment ID in the blinded path and uses it to make sure an incoming invoice really belongs to the payment it claims to belong to. That prevents an attacker who captures one blinded path from delivering a different payment's invoice over it, which could otherwise link two of the user's payments together. The change is mostly a cleanup, but it also tightens the matching logic slightly.

Recommended action

Review the downgrade path: ensure that a node running the new code, then downgraded to an older version that still requires the nonce, can read the persisted `Option<Nonce>` and retry/verify correctly. Also verify that `Bolt12Invoice::verify_using_metadata` robustly extracts the payment_id and that no code path still expects the removed nonce field. No urgent action is required; this is a defensive cleanup with a documented anti-correlation check.

Security signals we found

01

Removes a redundant nonce from blinded-path context, relying on payer metadata for invoice authentication

02

Retains and enforces payment_id matching to prevent cross-payment invoice delivery over captured blinded paths

03

Maintains backward-compatible persistence of the nonce for downgrade/retry scenarios

04

Updates serialization format for OffersContext and RetryableInvoiceRequest

05

Adds explicit security rationale in doc comments about preventing correlation of payments by an attacker holding a blinded path

Risk score

Why this scored 46/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 9/15
Affected reach 7/15
Confidence 7/10
Evidence quality 3/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.