đź“… Original date posted:2023-01-10
🗒️ Summary of this message: The open research question is how the sender will get an invoice from the receiver, given that they are offline at sending-time. One existing protocol extension that solves this is AMP.
đź“ť Original message:
Hi Val,
Happy to see ppl continue to work on the problem space after discussions and
brainstorming we had at the past LN Summit in Oakland.
> The open research question relates to how the sender will get an invoice
> from the receiver, given that they are offline at sending-time
One existing protocol extension that solves this is AMP [1][2]. The AMP
invoice is fully reusable (tho it can expire), and can be posted anywhere on
the internet, enabling a sender to at least _attempt_ the payment without
the receiver being online. As the sender is the one that generates the
pre-image, it's easy to prevent payment hash re-use (generate a new root
hash, just like you do a shared secret when making an onion). The LSP (or
anyone else) can't steal the funds, as the pre-image shares are in the final
hop of the onion payload, which can only be decrypted by the receiver.
Each payment can use the payment_addr/payment_secret field in the
invoice, but then also generate a new set_id for each logical payment. The
set_id is included in the final hop payload, which lets the receiver
aggregate the HTLCs until they can finally settle it after recovering the
root payment pre-image.
Invoice negotiation protocols such as BOLT 12, LN-URL, and Lightning Address
can also be used to fetch a self-contained AMP invoice.
Here's a testnet AMP invoice that can be paid w/ any amt:
```
lntb1p3murampp56m9m254s7xduktrm7g6j5r7qrpw9kvzc2tpqul7eskhyqfh95lnqdqqcqzpgxq9z0rgqsp5eyam7wajd3mmwk9qmfthzk3t96s0rklv05tc49ak68p8wvks0cmq9q8pqqqssq3jvnkdqn289fd7l3w2weqps89p9zaan4xlqenj3tmclwwkjgudrzn9jvvmkzgemehrdc7dlg4z7sxu0hmeul55keewqk0kdulc6058qpu644f8
```
> such that senders have proof-of-payment? This may ideally be built on top
> of PTLCs
I can't find the original slides (the old LN Conf URL seems to just redirect
to the Fulmo website now), but back in the day, Conner gave a talk about an
AMP extension he called "invoice tunneling". The idea is that you force the
receiver to reveal a unique secret bound to the invoice or payment attempt.
Rather than having the set_id be a 32-byte value, it would instead be a
point and mixed in along all the transmitted partial HTLC shares. In order
to settle the HTLC, both the secret of the point in the original invoice, as
well as the sender provided root payment pre-image would be required.
As usual though, I'm pretty dubious of any sort of "proof of payment"
schemes. Particularly given that virtual no wallets today (UI-wise) give you
direct access to a pre-image, there's no standard that has emerged yet
(seemingly due to a lack of an actual need) to encode such information, and
also most schemes would let any 3rd party that learned the pre-image (an
intermediate node) to claim that they sent the payment (w/o any other
asymmetric crypto).
Circling back to the discussion in Oakland, one of my key takeaways was
that: Trampoline payments are a critical part of any sort of async payment
scheme. Otherwise, you'll require the sender to be online in a synchronous
manner as _they're_ the ones that need to retry the payment continually.
With Trampoline payments, the sender's "LSP" can retry the payment at will
w/o needing to fetch a fresh onion each time. With that the entire flow can
be async:
1. user tries initial payment
2. LSP gets it, can delay the initial try to "phone home" to the receiver
3. HTLC eventually gets the penultimate (second to last hop before the
receiver)
4. Receiver comes online eventually to reveal pre-image
5. pre-image propagates backwards thru the route
6. sender eventually comes back online again to acknowledge receipt
With the way LN works, once step 4 is reached, then the payment has
effectively been completed from the PoV of the receiver (UI can update,
etc). With AMP usage, the receiver also doesn't need to be online for the
sender to even _attempt_ to make a payment.
-- Laolu
[1]: https://github.com/lightning/bolts/pull/658
[2]: https://docs.lightning.engineering/lightning-network-tools/lnd/amp
On Tue, Jan 10, 2023 at 11:41 AM vwallace via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi list!
>
> This email is a belated Christmas wishlist for interested researchers to
> solve an open question in lightning.
>
> For context, recently there’s been some discussion about supporting “async
> payments”[1]. Supporting this feature would mean that e.g. a mobile
> noncustodial user would be able to receive payments even if they’re
> regularly offline. See the linked email and preliminary spec PR[2] for
> details on this scheme.
>
> The open research question relates to how the sender will get an invoice
> from the receiver, given that they are offline at sending-time. If the
> receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of
> invoices ahead of time, and trust the LSP to never provide the same one
> twice, since doing this would allow the LSP (or some intermediate node on
> the path) to steal the funds, due to already knowing the preimage.
>
> This trust isn’t ideal, obviously. In the original ML email[1], the
> solution presented to this problem is PTLCs. However, upon further
> investigation, it turns out that the current PTLCs design wouldn’t solve
> this problem: the LSP would be able to steal funds the same as before, see
> [3].
>
> Note that even if we don’t want to trust LSPs, this problem doesn’t halt
> async payment progress entirely: the working solution for now is for the
> receiver’s LSP to provide a reusable keysend[4] invoice to senders. The
> current thinking is that BOLT12 invoices will add a feature bit to support
> keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to
> retrieve the keysend invoice. This isn’t ideal because it loses the
> proof-of-payment property, but it seems OK as a stopgap.
>
> So more specifically, the research question is: what is a scheme that
> allows a regularly-offline receiver to create a reusable invoice for their
> LSP to provide to senders, such that senders have proof-of-payment? This
> may ideally be built on top of PTLCs. **Note that while the recipient may
> be offline when the sender initiates the payment, the recipient will come
> back online some time later to fulfill the incoming payment.**
>
> A possible direction suggested by BlueMatt could be to stick with keysend,
> but have the sender encode a nonce + the time they sent the payment + the
> payment amount as a tweak to the keysend PTLC point (as well as in the
> onion), and make the receiver tweak their point with the same data when
> fulfilling the payment. Such a scheme may force the receiver to commit to
> the sender-encoded data[5], which wouldn’t exactly provide
> proof-of-payment, but would allow the sender to prove “I sent X amount at Y
> time.” Handwave handwave.
>
> Thoughts welcome!
>
> Cheers,
>
> Val
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>
>
> [2]: https://github.com/lightning/bolts/pull/989
>
> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>
> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/f1b1ffe6/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:12:29
in reply to nevent1q…r8hu
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:12:29Event JSON
{
"id": "93f41febd1cf288c6c8e10c505674344ce8bef85477d0d469d64252cb0f69f6c",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686316349,
"kind": 1,
"tags": [
[
"e",
"513a8ba55b7c93119bde84e386ef8cc1d555fd132a96a6ec92f423184c4e2892",
"",
"root"
],
[
"e",
"5c31dab0d0c38bc3b7e9486fa51f4ddde4ed7e1e58914d46c55f1a3649eb4a1d",
"",
"reply"
],
[
"p",
"ba0bbb05b42839cd4cbdd3a7315b6fc3608727356f7bac0d4bf3f0589436b476"
]
],
"content": "📅 Original date posted:2023-01-10\n🗒️ Summary of this message: The open research question is how the sender will get an invoice from the receiver, given that they are offline at sending-time. One existing protocol extension that solves this is AMP.\n📝 Original message:\nHi Val,\n\nHappy to see ppl continue to work on the problem space after discussions and\nbrainstorming we had at the past LN Summit in Oakland.\n\n\u003e The open research question relates to how the sender will get an invoice\n\u003e from the receiver, given that they are offline at sending-time\n\nOne existing protocol extension that solves this is AMP [1][2]. The AMP\ninvoice is fully reusable (tho it can expire), and can be posted anywhere on\nthe internet, enabling a sender to at least _attempt_ the payment without\nthe receiver being online. As the sender is the one that generates the\npre-image, it's easy to prevent payment hash re-use (generate a new root\nhash, just like you do a shared secret when making an onion). The LSP (or\nanyone else) can't steal the funds, as the pre-image shares are in the final\nhop of the onion payload, which can only be decrypted by the receiver.\n\nEach payment can use the payment_addr/payment_secret field in the\ninvoice, but then also generate a new set_id for each logical payment. The\nset_id is included in the final hop payload, which lets the receiver\naggregate the HTLCs until they can finally settle it after recovering the\nroot payment pre-image.\n\nInvoice negotiation protocols such as BOLT 12, LN-URL, and Lightning Address\ncan also be used to fetch a self-contained AMP invoice.\n\nHere's a testnet AMP invoice that can be paid w/ any amt:\n```\nlntb1p3murampp56m9m254s7xduktrm7g6j5r7qrpw9kvzc2tpqul7eskhyqfh95lnqdqqcqzpgxq9z0rgqsp5eyam7wajd3mmwk9qmfthzk3t96s0rklv05tc49ak68p8wvks0cmq9q8pqqqssq3jvnkdqn289fd7l3w2weqps89p9zaan4xlqenj3tmclwwkjgudrzn9jvvmkzgemehrdc7dlg4z7sxu0hmeul55keewqk0kdulc6058qpu644f8\n```\n\n\u003e such that senders have proof-of-payment? This may ideally be built on top\n\u003e of PTLCs\n\nI can't find the original slides (the old LN Conf URL seems to just redirect\nto the Fulmo website now), but back in the day, Conner gave a talk about an\nAMP extension he called \"invoice tunneling\". The idea is that you force the\nreceiver to reveal a unique secret bound to the invoice or payment attempt.\nRather than having the set_id be a 32-byte value, it would instead be a\npoint and mixed in along all the transmitted partial HTLC shares. In order\nto settle the HTLC, both the secret of the point in the original invoice, as\nwell as the sender provided root payment pre-image would be required.\n\nAs usual though, I'm pretty dubious of any sort of \"proof of payment\"\nschemes. Particularly given that virtual no wallets today (UI-wise) give you\ndirect access to a pre-image, there's no standard that has emerged yet\n(seemingly due to a lack of an actual need) to encode such information, and\nalso most schemes would let any 3rd party that learned the pre-image (an\nintermediate node) to claim that they sent the payment (w/o any other\nasymmetric crypto).\n\nCircling back to the discussion in Oakland, one of my key takeaways was\nthat: Trampoline payments are a critical part of any sort of async payment\nscheme. Otherwise, you'll require the sender to be online in a synchronous\nmanner as _they're_ the ones that need to retry the payment continually.\n\nWith Trampoline payments, the sender's \"LSP\" can retry the payment at will\nw/o needing to fetch a fresh onion each time. With that the entire flow can\nbe async:\n\n 1. user tries initial payment\n 2. LSP gets it, can delay the initial try to \"phone home\" to the receiver\n 3. HTLC eventually gets the penultimate (second to last hop before the\n receiver)\n 4. Receiver comes online eventually to reveal pre-image\n 5. pre-image propagates backwards thru the route\n 6. sender eventually comes back online again to acknowledge receipt\n\nWith the way LN works, once step 4 is reached, then the payment has\neffectively been completed from the PoV of the receiver (UI can update,\netc). With AMP usage, the receiver also doesn't need to be online for the\nsender to even _attempt_ to make a payment.\n\n-- Laolu\n\n[1]: https://github.com/lightning/bolts/pull/658\n[2]: https://docs.lightning.engineering/lightning-network-tools/lnd/amp\n\nOn Tue, Jan 10, 2023 at 11:41 AM vwallace via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi list!\n\u003e\n\u003e This email is a belated Christmas wishlist for interested researchers to\n\u003e solve an open question in lightning.\n\u003e\n\u003e For context, recently there’s been some discussion about supporting “async\n\u003e payments”[1]. Supporting this feature would mean that e.g. a mobile\n\u003e noncustodial user would be able to receive payments even if they’re\n\u003e regularly offline. See the linked email and preliminary spec PR[2] for\n\u003e details on this scheme.\n\u003e\n\u003e The open research question relates to how the sender will get an invoice\n\u003e from the receiver, given that they are offline at sending-time. If the\n\u003e receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of\n\u003e invoices ahead of time, and trust the LSP to never provide the same one\n\u003e twice, since doing this would allow the LSP (or some intermediate node on\n\u003e the path) to steal the funds, due to already knowing the preimage.\n\u003e\n\u003e This trust isn’t ideal, obviously. In the original ML email[1], the\n\u003e solution presented to this problem is PTLCs. However, upon further\n\u003e investigation, it turns out that the current PTLCs design wouldn’t solve\n\u003e this problem: the LSP would be able to steal funds the same as before, see\n\u003e [3].\n\u003e\n\u003e Note that even if we don’t want to trust LSPs, this problem doesn’t halt\n\u003e async payment progress entirely: the working solution for now is for the\n\u003e receiver’s LSP to provide a reusable keysend[4] invoice to senders. The\n\u003e current thinking is that BOLT12 invoices will add a feature bit to support\n\u003e keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to\n\u003e retrieve the keysend invoice. This isn’t ideal because it loses the\n\u003e proof-of-payment property, but it seems OK as a stopgap.\n\u003e\n\u003e So more specifically, the research question is: what is a scheme that\n\u003e allows a regularly-offline receiver to create a reusable invoice for their\n\u003e LSP to provide to senders, such that senders have proof-of-payment? This\n\u003e may ideally be built on top of PTLCs. **Note that while the recipient may\n\u003e be offline when the sender initiates the payment, the recipient will come\n\u003e back online some time later to fulfill the incoming payment.**\n\u003e\n\u003e A possible direction suggested by BlueMatt could be to stick with keysend,\n\u003e but have the sender encode a nonce + the time they sent the payment + the\n\u003e payment amount as a tweak to the keysend PTLC point (as well as in the\n\u003e onion), and make the receiver tweak their point with the same data when\n\u003e fulfilling the payment. Such a scheme may force the receiver to commit to\n\u003e the sender-encoded data[5], which wouldn’t exactly provide\n\u003e proof-of-payment, but would allow the sender to prove “I sent X amount at Y\n\u003e time.” Handwave handwave.\n\u003e\n\u003e Thoughts welcome!\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Val\n\u003e\n\u003e [1]:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html\n\u003e\n\u003e\n\u003e [2]: https://github.com/lightning/bolts/pull/989\n\u003e\n\u003e [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542\n\u003e\n\u003e [4]: https://github.com/lightning/blips/blob/master/blip-0003.md\n\u003e [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/f1b1ffe6/attachment-0001.html\u003e",
"sig": "bfbfe107e1f410de7a24e6742122a93cf837733acce263f3325ffdc68071f8a6b9b96c26f2c417b3e41d1ec1cfa2cc04df45bf6ee7e27a068bec8715a2350c53"
}