storage: store the bolt12invoice invoice #563
Conversation
.. 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. |
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?
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? |
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.