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

Commit to payment_metadata in inbound payment HMAC

Public commit record

What the developer wrote

Authored by Matt Corallo

95/100 · Strong
Commit to payment_metadata in inbound payment HMAC

When payment_metadata is set in a BOLT 11 invoice, users expect to
receive it back as-is in the payment onion. In order to ensure it
isn't tampered with, they presumably will add an HMAC, or worse, not
add one and forget that it can be tampered with.

Instead, here we include it in the HMAC computation for the payment
secret. This ensures that the sender must relay the correct
metadata for the payment to be accepted by the receiver, binding
the metadata to the payment cryptographically.

The metadata is only included in the HMAC when present, so existing
payments without metadata continue to verify correctly. However,
this does break receiving payments with metadata today. On an
upgrade this seems acceptable to me given we have seen almost no
use of payment metadata in practice.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ Specific, 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 change cryptographically ties a piece of invoice data called payment_metadata to the payment secret. Before, a sender could alter that metadata in flight and the receiver would still accept the payment. Now, if the metadata is changed, the payment will be rejected. The change is a security improvement, but it breaks compatibility for existing invoices that already include payment_metadata when nodes upgrade or downgrade.

Recommended action

Review any deployed systems that issue or receive BOLT 11 invoices with payment_metadata, because existing invoices will fail after this upgrade. Ensure all nodes in a payment path that use this feature are upgraded together. Consider whether the metadata should be encrypted before being placed in the invoice, as the commit message and new docs note it is exposed to the sender.

Security signals we found

01

Cryptographic binding of payment_metadata to payment secret via HMAC

02

Preimage derivation now includes payment_metadata

03

Verification now rejects payments where metadata was tampered with

04

Backwards-compatibility break for existing metadata-bearing invoices

05

New public API parameter for payment_metadata in invoice creation and inbound payment registration

Risk score

Why this scored 60/100

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