Include `Nonce` in `payer_metadata` again by jkczyz · Pull Request #4685 · lightningdevkit/rust-lightning

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz · 2026-06-12T03:29:59Z

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.
Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to confirm the invoice is for a request or refund we created, but is checked against the payment id recovered from a received Bolt12Invoice's payer metadata to ensure it arrived over the blinded path created for that payment, preventing an attacker from reusing one payment's blinded path to deliver another's invoice and correlate the two as ours.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

ldk-reviews-bot · 2026-06-12T03:30:02Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-12T03:36:27Z

Confirmed: nonce is a non-optional field always set in MetadataMaterial::new (signer.rs:234), so appending self.nonce.as_slice() at line 262 is always valid, and derive_metadata_and_keys now matches derive_metadata (line 246) in producing the encrypted_payment_id || nonce [+ hmac] layout. This is the same commit I reviewed previously, and the verification path remains internally consistent.

No issues found.

The PR is unchanged since my prior review pass. I re-verified the core build/verify agreement:

derive_metadata_and_keys (signer.rs:262) appends the nonce, matching derive_metadata (signer.rs:246); the nonce field is always populated, so no panic risk.
The verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext nonce removal/serialization cleanup, the refund IV-bytes selection in invoice.rs, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent — no dangling references, panics, or logic errors.

Cross-cutting note (non-blocking, acknowledged in the PR description): invoices for invoice-requests/refunds-with-paths created by the prior commit (df5d7ea7b) carry 32-byte payer metadata lacking the nonce, so returning invoices for in-flight payments across an upgrade would fail verify_using_metadata and must be retried with a new payment_id. The downgrade direction is preserved via the retained nonce field.

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 (lightningdevkit#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>

ldk-reviews-bot · 2026-06-15T00:00:52Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-06-14T23:41:23Z

- /// [`InvoiceRequest`] and for deriving its signing keys.
+ /// Used when handling a received [`Bolt12Invoice`] to confirm it arrived over the reply path
+ /// created for this payment, rather than one an attacker could use to learn our identity by
+ /// observing which payment we make. The invoice itself is verified using its payer metadata.


"learn our identity by observing which payment we make" is a bit ambiguous. Maybe mention explicitly "reuse a blinded path from a different payment and correlate payments made by us"?

Updated to be more precise.

ldk-reviews-bot · 2026-06-15T00:03:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-06-15T00:04:12Z

Presumed dep of #4297

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>

TheBlueMatt · 2026-06-15T15:23:30Z

This is a quite-straightforward change, just gonna land.

jkczyz requested a review from TheBlueMatt June 12, 2026 03:31

jkczyz mentioned this pull request Jun 12, 2026
[RFC] Add BOLT 12 payer proof primitives #4297
Closed

jkczyz force-pushed the 2026-06-include-payer-nonce branch from bd796d0 to bc88836Compare June 12, 2026 04:44

TheBlueMatt previously approved these changes Jun 15, 2026
View reviewed changes

TheBlueMatt added the backport 0.3 label Jun 15, 2026

TheBlueMatt added this to the 0.3 milestone Jun 15, 2026

jkczyz dismissed TheBlueMatt’s stale review via 2f53b8aJune 15, 2026 14:52

jkczyz force-pushed the 2026-06-include-payer-nonce branch from bc88836 to 2f53b8aCompare June 15, 2026 14:52

jkczyz requested a review from TheBlueMatt June 15, 2026 14:53

jkczyz force-pushed the 2026-06-include-payer-nonce branch from 2f53b8a to b910f8eCompare June 15, 2026 15:11

TheBlueMatt approved these changes Jun 15, 2026
View reviewed changes

TheBlueMatt merged commit 85a8cb1 into lightningdevkit:mainJun 15, 2026
1 check passed

notmandatory mentioned this pull request Jun 21, 2026
Socratic Seminar #45 NashBitDevs/nashbitdevs.org#142
Closed