Add BOLT 12 payer proof support - #845
Draft
vincenzopalazzo wants to merge 6 commits into
Draft
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
vincenzopalazzo
marked this pull request as draft
March 25, 2026 17:13
vincenzopalazzo
changed the title
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
2 times, most recently
from
March 26, 2026 15:42
18e0c72 to
312b662
Compare
Closed
7 tasks
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
from
March 26, 2026 15:55
312b662 to
4e593b7
Compare
tnull
self-requested a review
March 26, 2026 17:28
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
4 times, most recently
from
March 26, 2026 18:46
781d3ee to
0aaab83
Compare
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
from
April 2, 2026 12:17
26899ae to
a0641a2
Compare
tnull
reviewed
Apr 2, 2026
| (3, quantity, option), | ||
| (4, secret, option), | ||
| (6, offer_id, required), | ||
| (8, bolt12_invoice, option), |
Collaborator
There was a problem hiding this comment.
As mentioned elsewhere, we probably don't want to do this, at least not before we can use #811
| scorer: Arc<Mutex<Scorer>>, | ||
| peer_store: Arc<PeerStore<Arc<Logger>>>, | ||
| payment_store: Arc<PaymentStore>, | ||
| payer_proof_context_store: Arc<PayerProofContextStore>, |
Collaborator
There was a problem hiding this comment.
No, I'd rather not add yet another store just for this. Can we store this in the payment metadata store post #811?
Member
Author
There was a problem hiding this comment.
yes OFC, I wanted to have a runnable version in a fork, but currently I am interesting in you giving some feedback on the payer proof API, if you think are good enough!
Thanks after ldk 0.3 I can wait for #811 and vibe code another integration :)
The switch to tracking payments by ID happened with LDK Node v0.3.0, which is >1.5 years old by now. We can be pretty certain that nobody is upgrading from an older version to the upcoming v0.8. Here we hence make the `payment_id` fields in `Event` required which is a nice API simplification that will also be utilized in the next commit. Co-Authored-By: HAL 9000
Gate manual claiming for unknown custom-hash BOLT11 payments behind a config flag. Nodes that do not opt in fail these payments back without storing or queueing user events. Co-Authored-By: HAL 9000
Create inbound BOLT11 records from claimable and claimed events so inbound payments can be tracked by the IDs emitted by LDK. Generate outbound BOLT11 IDs from KeysManager entropy instead of deriving them from the payment hash. Co-Authored-By: HAL 9000
Cover manually claiming and failing BOLT11 for-hash invoices that were created before upgrading, so the new ID-based APIs keep handling legacy payment-hash IDs. Co-Authored-By: HAL 9000
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
from
August 11, 2026 09:15
5f40753 to
351cf83
Compare
Add a `bolt12_invoice` field to `PaymentKind::Bolt12Offer` and `PaymentKind::Bolt12Refund`, and set it from `Event::PaymentSent` when a BOLT 12 payment succeeds. Besides being useful on its own, this gives us everything we need to build a payer proof for a past payment without keeping any additional state around: the invoice is persisted alongside the payment and thus survives restarts. This commit was written with AI assistance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
from
August 11, 2026 10:10
351cf83 to
82de0c7
Compare
vincenzopalazzo
changed the title
Expose `Bolt12Payment::create_payer_proof`, which builds a BOLT 12 payer proof for a previously succeeded outbound BOLT 12 payment, with `PayerProofOptions` controlling which optional invoice fields are selectively disclosed. The proof is built purely from data we already persist in the payment store: the paid BOLT 12 invoice recorded on `PaymentKind::Bolt12Offer` / `PaymentKind::Bolt12Refund` and the payment preimage. That means payer proofs survive restarts and we don't need a second, node-lifetime-only store to keep the invoice context around. Payments that completed via a static invoice, i.e., async payments, don't support payer proofs and are rejected with `PayerProofUnavailable`. Also wires the new `PayerProof` type and the two new error variants through the UniFFI surface. This commit was written with AI assistance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vincenzopalazzo
force-pushed
the
macros/bolt12-pop
branch
from
August 11, 2026 10:36
82de0c7 to
fbb3a7c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds support for building BOLT 12 payer proofs for previously succeeded outbound BOLT 12 payments:
PaymentKind::Bolt12Offer/PaymentKind::Bolt12Refund, set fromEvent::PaymentSentonce the payment succeeds.Bolt12Payment::create_payer_proof, which builds a payer proof from the persisted invoice and payment preimage.PayerProofOptionscontrols which optional invoice fields (offer description, issuer, amount, creation time, extra TLV types) are selectively disclosed, plus an optional proof note.PayerProoftype and error variants (PayerProofCreationFailed,PayerProofUnavailable,InvalidPayerProof) through the UniFFI surface.Since the proof is built purely from data persisted in the payment store, payer proofs survive restarts without any additional storage: no new KV namespace and no in-memory side store. Payments that completed via a static invoice (async payments) do not support payer proofs and are rejected with
PayerProofUnavailable.This PR is based on (and currently includes the commits of) #948, since it builds on the payment-id tracking prefactors. Only the last two commits are new here. The payer proof primitives landed in the
rust-lightningrevision pinned by #948, so this PR no longer patches LDK to a fork —Cargo.tomlis untouched.Verification
cargo fmt --all -- --checkcargo check --lib --tests --benches,cargo check --lib --features unifficargo clippy --lib -- -A warnings -D clippy::unwrap_used -A clippy::tabs_in_doc_commentscargo test --lib,cargo test --test upgrade_downgrade_testscargo test --test integration_tests_rust simple_bolt12_send_receive— extended to build a payer proof from the persisted payment and assert the payment hash, disclosed amount, proof note, and that undisclosed fields stay absentscripts/uniffi_bindgen_generate_python.sh)Disclosure
This PR was prepared with AI assistance (Claude Code).
🤖 Generated with Claude Code