Olaoluwa Osuntokun [ARCHIVE] on Nostr: đź“… Original date posted:2023-01-10 đź“ť Original message: Hi Val, Happy to see ppl ...
đź“… Original date posted:2023-01-10
đź“ť 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>;
đź“ť 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>;