You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently don't support proof of payment for sent BOLT 12 payments because the user needs the Bolt12Invoice in the PaymentSentEvent. This will require a bit of involvement, we'll need to store the Bolt12Invoice in the ChannelMonitorUpdates for sent payments so we can restore them if the ChannelManager is stale on reload. When we do this we should also include DNSSECProof objects from #3179 so that we get BIP 353 proof of payment too. cc @jkczyz
IIUC, for BOLT11 payments, the onus is on the user to maintain a copy of the invoice. Any reason why we wouldn't do the same for BOLT12 payments? It would require using manually_handle_bolt12_invoices.
Because using manually_handle_bolt12_invoices requires a bunch of work, but PoP is something we should encourage all our users to maintain. If we want to require manually_handle_bolt12_invoices for PoP IMO we should completely remove support for !manually_handle_bolt12_invoices.
Just for proof of payment do you think that would be a nice idea to pop out the invoice through an event? and then also together with the payment completed notification?
For payment proof what you need is that at some point you can get the invoice somewhere.
Not sure if the case that I described is included with the manually_handle_bolt12_invoices, I need to look more inside the code for it
Yea, we could have a separate event for it, but its definitely nicer for the user if we provide it all in one go, and I'm not sure its that much work to do so, just a question of piping the invoice through a few state machine states and popping it back out when we get the preimage.
Since I am already going down this proof of payment rabbit hole in other projects, and Jeff isn’t looking into it yet, I could explore this task a bit further.
This is still pretty important, but everyone has gotten slammed with three other projects, so sadly slipped. We should re-circle in time for 0.2.
Ops! I did not receive any notification about this and I forgot to assume that it was already taken! If there is not much time to push this in 0.1, I will take it for the next release.
@TheBlueMatt is the 0.1 scheduled before the Christmas holiday? probably next week?
Activity
jkczyz commentedon Oct 2, 2024
IIUC, for BOLT11 payments, the onus is on the user to maintain a copy of the invoice. Any reason why we wouldn't do the same for BOLT12 payments? It would require using
manually_handle_bolt12_invoices.TheBlueMatt commentedon Oct 8, 2024
Because using
manually_handle_bolt12_invoicesrequires a bunch of work, but PoP is something we should encourage all our users to maintain. If we want to requiremanually_handle_bolt12_invoicesfor PoP IMO we should completely remove support for!manually_handle_bolt12_invoices.vincenzopalazzo commentedon Oct 10, 2024
Just for proof of payment do you think that would be a nice idea to pop out the invoice through an event? and then also together with the payment completed notification?
For payment proof what you need is that at some point you can get the invoice somewhere.
Not sure if the case that I described is included with the
manually_handle_bolt12_invoices, I need to look more inside the code for itTheBlueMatt commentedon Oct 16, 2024
Yea, we could have a separate event for it, but its definitely nicer for the user if we provide it all in one go, and I'm not sure its that much work to do so, just a question of piping the invoice through a few state machine states and popping it back out when we get the preimage.
vincenzopalazzo commentedon Oct 17, 2024
Since I am already going down this proof of payment rabbit hole in other projects, and Jeff isn’t looking into it yet, I could explore this task a bit further.
TheBlueMatt commentedon Dec 8, 2024
This is still pretty important, but everyone has gotten slammed with three other projects, so sadly slipped. We should re-circle in time for 0.2.
vincenzopalazzo commentedon Dec 8, 2024
Ops! I did not receive any notification about this and I forgot to assume that it was already taken! If there is not much time to push this in 0.1, I will take it for the next release.
@TheBlueMatt is the 0.1 scheduled before the Christmas holiday? probably next week?
TheBlueMatt commentedon Dec 9, 2024
Not a huge deal, this isn't that critical, given the long burn that BOLT 12 adoption will be/is. Indeed, we're targeting 0.1 (beta) by next week.
make persistent BOLT12 invoice through PendingOutboundPayment
make persistent BOLT12 invoice through PendingOutboundPayment
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
43 remaining items
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
add the bolt12 invoice to the PaymentSend event
Include DNSSECProof in PaymentSent for BIP 353 proof of payment
Include DNSSECProof in PaymentSent for BIP 353 proof of payment
Include DNSSECProof in PaymentSent for BIP 353 proof of payment