storage: store the bolt12invoice invoice #563
Draft
Conversation
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
.. as having them in two places doesn't make sense
.. we now apply the LSPS2 client-side overrides on a per-counterparty basis, not as soon as we act as an LSP client
.. we implement the `async` version of `ChangeDestinationSource`, and, to make all involved objects `Send`, we drop the `Deref` generics for concrete `Arc`s everywhere.
This commit enhances the BOLT12 payment storage capabilities by adding support for storing the actual BOLT12 invoice along with payment details. We modify the following components: - Added `bolt12_invoice` field to `PaymentKind::Bolt12Offer` and `PaymentKind::Bolt12Refund` variants in the payment store - Updated event handling in `event.rs` to capture and store the BOLT12 invoice when payments are processed - Modified BOLT12 payment creation logic to initialize the new field - Enhanced payment update mechanism to handle BOLT12 invoice updates - Added comprehensive test coverage for the new invoice storage feature This improvement allows for proof of payment and to access the BOLT12 invoice details. Signed-off-by: Vincenzo Palazzo <[email protected]>
|
👋 Hi! I see this is a draft PR. |
tnull
reviewed
Jun 6, 2025
Collaborator
There was a problem hiding this comment.
So, while I'd be open to expose the paid invoice, e.g, via the PaymentSuccessful event, I don't think we'd want to store it in the payment store. Post-#425 we might be able to add it in the payment metadata store.
Maybe it would be cleanest if you applied the approach in this PR to your fork, and then we go the payment-metadata-store route once it becomes unblocked?
Contributor
Author
This makes sense to me too, and looks like the easy approach too, without touching the storage.
Yeah makes super sense! I can keep this PR open in draft, and then you will close it when it is ready on the mainline? or just follow up with me if you want that I will modify the PR to apply the new behaviour? |
vincenzopalazzo
added a commit
to vincenzopalazzo/ldk-node
that referenced
this pull request
Dec 29, 2025
This patch adds the `bolt12_invoice` field to the `PaymentSuccessful` event, enabling users to obtain proof of payment for BOLT12 transactions. Problem: Previously, after a successful BOLT12 payment, users had no way to access the paid invoice data. This made it impossible to provide proof of payment to third parties, who need both the payment preimage and the original invoice to verify that sha256(preimage) matches the invoice's payment_hash. Solution: Add a `bolt12_invoice: Option<Vec<u8>>` field to `PaymentSuccessful` that contains the serialized BOLT12 invoice bytes. The invoice is serialized using LDK's standard encoding, which can be parsed back using `Bolt12Invoice::try_from(bytes)` in native Rust, or by hex-encoding the bytes and using `Bolt12Invoice.from_str()` in FFI bindings. Design decisions: - Store as `Vec<u8>` rather than the complex `PaidBolt12Invoice` type to avoid UniFFI limitations with objects in enum variants - Return `None` for `StaticInvoice` (async payments) since proof of payment is not possible for those payment types anyway - Use TLV tag 7 for serialization, maintaining backward compatibility with existing persisted events This implementation follows the maintainer guidance from PR lightningdevkit#563 to expose the invoice via the event rather than storing it in the payment store. Signed-off-by: Vincenzo Palazzo <[email protected]>
vincenzopalazzo
added a commit
to vincenzopalazzo/ldk-node
that referenced
this pull request
Dec 29, 2025
This patch adds the `bolt12_invoice` field to the `PaymentSuccessful` event, enabling users to obtain proof of payment for BOLT12 transactions. Problem: Previously, after a successful BOLT12 payment, users had no way to access the paid invoice data. This made it impossible to provide proof of payment to third parties, who need both the payment preimage and the original invoice to verify that sha256(preimage) matches the invoice's payment_hash. Solution: Add a `bolt12_invoice: Option<Vec<u8>>` field to `PaymentSuccessful` that contains the serialized BOLT12 invoice bytes. The invoice is serialized using LDK's standard encoding, which can be parsed back using `Bolt12Invoice::try_from(bytes)` in native Rust, or by hex-encoding the bytes and using `Bolt12Invoice.from_str()` in FFI bindings. Design decisions: - Store as `Vec<u8>` rather than the complex `PaidBolt12Invoice` type to avoid UniFFI limitations with objects in enum variants - Return `None` for `StaticInvoice` (async payments) since proof of payment is not possible for those payment types anyway - Use TLV tag 7 for serialization, maintaining backward compatibility with existing persisted events This implementation follows the maintainer guidance from PR lightningdevkit#563 to expose the invoice via the event rather than storing it in the payment store. Signed-off-by: Vincenzo Palazzo <[email protected]>
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.
Based on #462
Review only the commits a88e206
This commit is leveraging the feature implemented in lightningdevkit/rust-lightning#3593 to implement proof of payment.
This is really useful when LDK-node is going to be used on the side of other lightning nodes and the backend wants to know about the bolt12 invoice.