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

offers: add BOLT 12 payer proof primitives

Public commit record

What the developer wrote

Authored by Vincenzo Palazzo

86/100 · Strong
offers: add BOLT 12 payer proof primitives

Add the `payer_proof` module: `PayerProof`/`UnsignedPayerProof`, the
`PayerProofBuilder` (with selective disclosure and a derived-key path), bech32
`lnp` encoding, and parse-time verification, implementing the payer proof
extension to BOLT 12 (https://github.com/lightning/bolts/pull/1295). Also
exposes the offer/invoice TLV-type constants and an invoice-bytes accessor used
to build proofs, and a `Sha256` `Writeable`/`Readable` impl for the proof hashes.

Co-Authored-By: Rusty Russell <rusty@rustcorp.com.au>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Co-Authored-By: OpenAI Codex <codex@openai.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 adds a new feature to rust-lightning called BOLT 12 payer proofs. It lets someone who paid a BOLT 12 invoice cryptographically prove they paid it, while optionally hiding some invoice details. The change is a large new module plus small supporting changes in invoice, offer, nonce, and serialization code. There is no indication this is a security patch or fixes a vulnerability; it is a new protocol feature implementation with extensive tests and spec test vectors.

Recommended action

Review as a normal feature addition. Ensure the new payer proof parsing, selective disclosure, and signature verification logic are covered by the included tests and spec vectors. No urgent security action is indicated by the commit itself.

Security signals we found

01

New cryptographic proof-of-payment feature, not a vulnerability fix

02

Extensive parse-time validation: preimage hash match, issuer signature, payer signature, TLV ordering, duplicate rejection, omitted-marker minimization

03

Selective disclosure logic relies on merkle tree reconstruction; correctness is backed by spec test vectors

04

Small change to `EXPERIMENTAL_INVOICE_TYPES` range from `RangeFrom` to bounded `Range` (3_000_000_000..4_000_000_000) to align with payer proof validation

05

No vendor or researcher attribution to a security issue

Risk score

Why this scored 32/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/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.