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

ln: persist the paid BOLT 12 invoice and build payer proofs

Public commit record

What the developer wrote

Authored by Vincenzo Palazzo

83/100 · Strong
ln: persist the paid BOLT 12 invoice and build payer proofs

Carry the paid `Bolt12Invoice` through the outbound payment so it survives
restarts, and surface it as a `PaidBolt12Invoice` on `Event::PaymentSent` so the
payer can build a payer proof. The payer signing key is re-derived from the
invoice's own payer metadata, so no extra key material is stored.

`PaidBolt12Invoice` now lives in `offers::payer_proof`; existing async payment
tests and a test helper are updated to construct it via the new API. Adds an
end-to-end test that pays a BOLT 12 offer and builds + verifies a payer proof
from the resulting `Event::PaymentSent`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a feature addition, not a vulnerability fix. It extends rust-lightning's BOLT 12 payment support so that when a wallet pays a BOLT 12 invoice, the paid invoice is saved through retries and restarts and is later exposed in the PaymentSent event as a PaidBolt12Invoice. The wallet can then use that object to build a cryptographic 'payer proof' that selectively discloses invoice fields to prove to a third party that it paid. The payer signing key is re-derived from data already in the invoice, so no extra secret key storage is needed. There is no indication in the commit that this fixes a security bug; it is new functionality with tests.

Recommended action

Treat as a normal feature commit. Review the new PayerProof construction and serialization paths for correctness, ensure the re-derived payer signing key cannot be misused to sign arbitrary data, and verify that persisted PaidBolt12Invoice data is handled consistently across upgrades. No immediate security response is warranted based on the supplied materials.

Security signals we found

01

New BOLT 12 payer proof feature: persists paid invoice across retries/restarts and exposes it in Event::PaymentSent

02

Payer signing key re-derived from invoice payer metadata rather than storing extra key material

03

Adds end-to-end test for proof creation, verification, and bech32 round-trip

04

Adds serialization round-trip test for Retryable payment carrying bolt12_invoice

05

No security bug fix language, CVE references, or vulnerability disclosure present in commit or diff

Risk score

Why this scored 25/100

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