[RFC] event: expose BOLT12 invoice in PaymentSuccessful for proof of payment#733
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
|
@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 |
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @tnull! This PR has been waiting for your review. |
tnull
left a comment
There was a problem hiding this comment.
Exposing the BOLT12 invoice makes sense to me, though we should do it properly instead of just exposing the bytes.
4c6b18e to
a3a60b3
Compare
There was a problem hiding this comment.
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.
22abd3b to
a8d05cb
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. |
327a59a to
e6200d6
Compare
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
@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 |
025fea4 to
991fa56
Compare
971aee2 to
cd7c42d
Compare
|
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 |
tnull
left a comment
There was a problem hiding this comment.
Cool, mostly looks good, just some comments regarding cleanups we should now be able to do?
cd7c42d to
00e26c0
Compare
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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>
00e26c0 to
3c724a9
Compare
This patch adds the
bolt12_invoicefield to thePaymentSuccessfulevent, 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 toPaymentSuccessfulthat contains the serialized BOLT12 invoice bytes. The invoice is serialized using LDK's standard encoding, which can be parsed back usingBolt12Invoice::try_from(bytes)in native Rust, or by hex-encoding the bytes and usingBolt12Invoice.from_str()in FFI bindings.Design decisions:
Vec<u8>rather than the complexPaidBolt12Invoicetype to avoid UniFFI limitations with objects in enum variantsNoneforStaticInvoice(async payments) since proof of payment is not possible for those payment types anywayThis implementation follows the maintainer guidance from PR #563 to expose the invoice via the event rather than storing it in the payment store.