Skip to content

[RFC] event: expose BOLT12 invoice in PaymentSuccessful for proof of payment#733

Merged
tnull merged 1 commit intolightningdevkit:mainfrom
vincenzopalazzo:macros/bolt12-pop
Mar 4, 2026
Merged

[RFC] event: expose BOLT12 invoice in PaymentSuccessful for proof of payment#733
tnull merged 1 commit intolightningdevkit:mainfrom
vincenzopalazzo:macros/bolt12-pop

Conversation

@vincenzopalazzo
Copy link
Contributor

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 #563 to expose the invoice via the event rather than storing it in the payment store.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Dec 29, 2025

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@vincenzopalazzo
Copy link
Contributor Author

@tnull IDK if this is a good design to have with the ffi, but I had to work around some unify ffi limitation with the enum type that is used inside the PaymentSend in rust-lightning

@vincenzopalazzo vincenzopalazzo marked this pull request as ready for review December 29, 2025 13:53
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exposing the BOLT12 invoice makes sense to me, though we should do it properly instead of just exposing the bytes.

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes are getting closer, but please make sure to avoid unnecessary boilerplate and stick to the approach we took for the other types (like Offer, Refund, etc).

This also needs a rebase by now, sorry!

Btw, please re-request review when you made updates, otherwise I might not always see it immediately.

@vincenzopalazzo vincenzopalazzo force-pushed the macros/bolt12-pop branch 4 times, most recently from 22abd3b to a8d05cb Compare January 10, 2026 12:05
@vincenzopalazzo vincenzopalazzo requested a review from tnull January 10, 2026 12:09
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@tnull
Copy link
Collaborator

tnull commented Mar 2, 2026

@vincenzopalazzo We now landed the uniffi v0.29 upgrade, so this should be unblocked. Note that as part of that upgrade we switched to use proc macros where possible, in particular Event is no longer exposed via the UDL file. So this should be unblocked, please rebase and let me know how it goes!

@vincenzopalazzo vincenzopalazzo force-pushed the macros/bolt12-pop branch 2 times, most recently from 025fea4 to 991fa56 Compare March 2, 2026 15:26
@vincenzopalazzo vincenzopalazzo force-pushed the macros/bolt12-pop branch 3 times, most recently from 971aee2 to cd7c42d Compare March 2, 2026 17:19
@vincenzopalazzo vincenzopalazzo requested a review from tnull March 2, 2026 17:32
@vincenzopalazzo
Copy link
Contributor Author

Thanks @tnull I used the help of claude to navigate a little bit the changes and now I pushed it (I have to change some name inside the enum for the kotlin naming convention hope this is not a big deal.

Please let me know if this is good enough or if there is a better way to implement the functionality in the codebase, thanks

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, mostly looks good, just some comments regarding cleanups we should now be able to do?

src/ffi/types.rs Outdated
impl Writeable for PaidBolt12Invoice {
fn write<W: Writer>(&self, w: &mut W) -> Result<(), lightning::io::Error> {
// We clone `self` to convert it into the LDK native type for serialization.
// This only runs during event persistence, so the overhead is acceptable.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, this is still pretty bad. We should really avoid this, though I played with the different options here and I'm still not sure what else I find preferable. Seems every approach that avoids cloning the data (in particular struct wrapping for uniffi) will revert back to a lot of complications.

Let's make this comment a TODO: Find way to avoid cloning invoice data so I don't totally forget to revisit this, and then we should be able to move forward here to unblock you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was not able to avoid it because the into() will close the type anyway, and I do not think it is a good idea to duplicate the code here, but probably I am underestimating how many times this method is called?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I updated the comment! Thanks for the feedback

…ment

Add the `bolt12_invoice: Option<PaidBolt12Invoice>` field to the
`PaymentSuccessful` event, enabling users to obtain proof of payment
for BOLT12 transactions.

For non-uniffi builds, import `PaidBolt12Invoice` directly from
`lightning::events` rather than re-exporting through `types.rs`.
For uniffi builds, use the custom `ffi::PaidBolt12Invoice` wrapper
that handles Arc-wrapping for enum variants.

The proof-of-payment assertion is integrated into the existing
`simple_bolt12_send_receive` test rather than a separate test.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Landing this. I think after #811 we could explore whether it makes sense to move the invoice to be stored in PaymentMetadataStore. Now tracked at #816

@tnull tnull merged commit fae2746 into lightningdevkit:main Mar 4, 2026
17 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants