Support async payments in BOLT 12 #1149

valentinewallace · 2024-03-19T17:59:01Z

This builds on #989 by adding the ability to fetch an invoice from an
always-online node on behalf of an often-offline recipient, e.g. a mobile node.

The idea is that often-offline recipients will supply some always-online node
such as their wallet vendor with a static keysend (i.e. payment_hash-less)
invoice to return on its behalf. The recipient will then publish an offer
containing blinded paths that terminate at this always-online node, who payers
can request the invoice from if the recipient is offline at the time. After
receiving the keysend invoice, payers will commence the protocol outlined in
1 to send the HTLC asynchronously.

Some context on the top commit where we include the invoice request in the payment onion:
This definitely warrants discussion, but the idea is that this field may be useful for often-offline recipients who did not receive the invoice request when it was originally sent. Recipients may want to verify the invreq or be provided some other relevant data about the payment, while keeping the payment stateless until an HTLC is actually received. For example, future extensions have been proposed 2 that require the recipient to know a unique token for a payment, and this field would provide that to them.

Seeking conceptual feedback! I'm also working on the implementation in LDK.

Based on ~~#798~~ and #989.

valentinewallace · 2024-06-03T17:25:55Z

Changed up the feature bits, required single-chain offers, and disallowed setting invoice_amount_msat for static invoices. Also moved away from the "keysend" language for clarity. These changes were based on implementing this in LDK in lightningdevkit/rust-lightning#3082, will take this out of draft once the design solidifies a bit more in that PR.

valentinewallace · 2024-06-24T20:26:29Z

Added a fixup requiring the invreq to be included in the payment onion per spec meeting discussion a week ago!

Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously. We use an experimental TLV type for this new onion payload field, since the spec is still not merged in the BOLTs.

Add a new invoice request parameter to onion_utils::build_onion_payloads. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to onion_utils::create_payment_onion. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to outbound_payments and channelmanager send-to-route internal utils. As of this commit the invreq will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

When transitioning outbound payments from AwaitingInvoice to StaticInvoiceReceived, include the invreq in the new state's outbound payment storage for future inclusion in an async payment onion. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously. We use an experimental TLV type for this new onion payload field, since the spec is still not merged in the BOLTs.

Add a new invoice request parameter to onion_utils::build_onion_payloads. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to onion_utils::create_payment_onion. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to outbound_payments and channelmanager send-to-route internal utils. As of this commit the invreq will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

When transitioning outbound payments from AwaitingInvoice to StaticInvoiceReceived, include the invreq in the new state's outbound payment storage for future inclusion in an async payment onion. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Past commits have set us up to include invoice requests in outbound async payment onions. Here we actually pull the invoice request from where it's stored in outbound_payments and pass it into the correct utility for inclusion in the onion on initial send. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

While in the last commit we began including invoice requests in async payment onions on initial send, further work is needed to include them on retry. Here we begin storing invreqs in our retry data, and pass them along for inclusion in the onion on payment retry. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously. We use an experimental TLV type for this new onion payload field, since the spec is still not merged in the BOLTs.

Add a new invoice request parameter to onion_utils::build_onion_payloads. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to onion_utils::create_payment_onion. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to outbound_payments and channelmanager send-to-route internal utils. As of this commit the invreq will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

When transitioning outbound payments from AwaitingInvoice to StaticInvoiceReceived, include the invreq in the new state's outbound payment storage for future inclusion in an async payment onion. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Past commits have set us up to include invoice requests in outbound async payment onions. Here we actually pull the invoice request from where it's stored in outbound_payments and pass it into the correct utility for inclusion in the onion on initial send. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

While in the last commit we began including invoice requests in async payment onions on initial send, further work is needed to include them on retry. Here we begin storing invreqs in our retry data, and pass them along for inclusion in the onion on payment retry. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

This is an incredibly simple first start towards the protocol sketched out at [1]. It adds the ability to have a counteraprty hold an HTLC before forwarding it. Specifically, the HTLC sender sets a required TLV on the `update_add_htlc` message and sends an onion message to the final recipient. From there, the final recipient uses the included `reply_path` to notify the sender's counterparty that they're online and ready to receive the HTLC. In order to fully flesh out the protocol as sketched, we'll need to add an onion message mailbox service (which should be as simple as a new feature bit), add PTLCs, and extensions to BOLT 12 to allow signaling that the final recipient is often-offline. While we could add such signaling to BOLT 11, there's not a whole lot of reason to - if the recipient is able to provide an invoice, they're currently online! [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html

This builds on prior commits by adding the ability to fetch an invoice from an always-online node on behalf of an often-offline recipient, e.g. a mobile node. The idea is that often-offline recipients will supply some always-online node such as their wallet vendor with a static (i.e. `payment_hash`-less) invoice to return on its behalf. The recipient will then publish an offer containing blinded paths that terminate at this always-online node, who payers can request the invoice from if the recipient is offline at the time. After receiving the static invoice, payers will commence the protocol outlined in [1] to send the HTLC asynchronously. [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html

This field may be useful for often-offline recipients who did not receive the invreq when it was originally sent, due to another node providing a static invoice on their behalf. Recipients may want to verify the invreq or be provided some other relevant data about the payment while remaining stateless until an HTLC is actually received.

valentinewallace · 2024-10-25T20:59:05Z

Rebased after merge of #798 🎉

Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously. We use an experimental TLV type for this new onion payload field, since the spec is still not merged in the BOLTs.

Add a new invoice request parameter to onion_utils::build_onion_payloads. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to onion_utils::create_payment_onion. As of this commit it will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Add a new invoice request parameter to outbound_payments and channelmanager send-to-route internal utils. As of this commit the invreq will always be passed in as None, to be updated in future commits. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

When transitioning outbound payments from AwaitingInvoice to StaticInvoiceReceived, include the invreq in the new state's outbound payment storage for future inclusion in an async payment onion. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

Past commits have set us up to include invoice requests in outbound async payment onions. Here we actually pull the invoice request from where it's stored in outbound_payments and pass it into the correct utility for inclusion in the onion on initial send. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

While in the last commit we began including invoice requests in async payment onions on initial send, further work is needed to include them on retry. Here we begin storing invreqs in our retry data, and pass them along for inclusion in the onion on payment retry. Per <lightning/bolts#1149>, when paying a static invoice we need to include our original invoice request in the HTLC onion since the recipient wouldn't have received it previously.

valentinewallace mentioned this pull request Mar 19, 2024

Async Payments lightningdevkit/rust-lightning#2298

Open

24 tasks

t-bast mentioned this pull request Mar 20, 2024

Lightning Specification Meeting 2024/03/25 #1150

Closed

21 tasks

Roasbeef mentioned this pull request Apr 8, 2024

Lightning Specification Meeting 2024/04/08 #1152

Closed

21 tasks

t-bast mentioned this pull request Apr 18, 2024

Lightning Specification Meeting 2024/04/22 #1155

Closed

22 tasks

t-bast mentioned this pull request May 2, 2024

Lightning Specification Meeting 2024/05/06 #1161

Closed

25 tasks

t-bast mentioned this pull request May 14, 2024

Lightning Specification Meeting 2024/05/20 #1164

Closed

23 tasks

valentinewallace mentioned this pull request May 23, 2024

BOLT 12 static invoice encoding and building lightningdevkit/rust-lightning#3082

Merged

2 tasks

t-bast mentioned this pull request Jun 3, 2024

Lightning Specification Meeting 2024/06/03 #1167

Closed

23 tasks

valentinewallace force-pushed the 2024-02-async-payments branch from 10f0c5b to dc6599f Compare June 3, 2024 17:16

t-bast mentioned this pull request Jun 17, 2024

Lightning Specification Meeting 2024/06/17 #1172

Closed

22 tasks

valentinewallace mentioned this pull request Jun 24, 2024

Support paying static invoices lightningdevkit/rust-lightning#3140

Merged

t-bast mentioned this pull request Jun 26, 2024

Lightning Specification Meeting 2024/07/01 #1175

Closed

23 tasks

valentinewallace force-pushed the 2024-02-async-payments branch from 5a36154 to 5b5fd7f Compare June 26, 2024 18:13

bshramin mentioned this pull request Jun 29, 2024

Fix broken link to BOLT 12 in 04-onion-routing.md #1177

Closed

t-bast mentioned this pull request Jul 12, 2024

Lightning Specification Meeting 2024/07/15 #1183

Closed

22 tasks

valentinewallace mentioned this pull request Jul 18, 2024

Trampoline Routing (2021 edition) (Feature 56/57) #829

Open

fusion44 mentioned this pull request Jul 21, 2024

TODO: Add support for Bolt12 fusion44/dart_bolt11_decoder#8

Open

t-bast mentioned this pull request Jul 23, 2024

Lightning Specification Meeting 2024/07/29 #1185

Closed

23 tasks

valentinewallace mentioned this pull request Jul 26, 2024

Include invoice requests in async payment onions lightningdevkit/rust-lightning#3207

Merged

2 tasks

t-bast mentioned this pull request Aug 9, 2024

Lightning Specification Meeting 2024/08/12 #1187

Closed

21 tasks

t-bast mentioned this pull request Aug 23, 2024

Lightning Specification Meeting 2024/08/26 #1191

Closed

20 tasks

t-bast mentioned this pull request Sep 6, 2024

Lightning Specification Meeting 2024/09/09 #1195

Closed

20 tasks

t-bast mentioned this pull request Sep 18, 2024

Add specs for offline payments #819

Closed

TheBlueMatt and others added 4 commits October 25, 2024 12:25

Add an init/node feature for HTLC holding

5bee6ab

valentinewallace force-pushed the 2024-02-async-payments branch from 5b5fd7f to 5d69269 Compare October 25, 2024 20:58

valentinewallace mentioned this pull request Nov 14, 2024

Add static invoice creation utils to ChannelManager lightningdevkit/rust-lightning#3408

Open

t-bast mentioned this pull request Nov 22, 2024

Lightning Specification Meeting 2024/12/02 #1210

Closed

19 tasks

t-bast mentioned this pull request Dec 9, 2024

Lightning Specification Meeting 2024/12/16 #1213

Open

19 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support async payments in BOLT 12 #1149

Support async payments in BOLT 12 #1149

valentinewallace commented Mar 19, 2024 •

edited

Loading

valentinewallace commented Jun 3, 2024

valentinewallace commented Jun 24, 2024

valentinewallace commented Oct 25, 2024

Support async payments in BOLT 12 #1149

Are you sure you want to change the base?

Support async payments in BOLT 12 #1149

Conversation

valentinewallace commented Mar 19, 2024 • edited Loading

valentinewallace commented Jun 3, 2024

valentinewallace commented Jun 24, 2024

valentinewallace commented Oct 25, 2024

valentinewallace commented Mar 19, 2024 •

edited

Loading