Hi Laolu,
To your point about AMP – yeah, posting an AMP invoice or serving it over
LNURL/BOLT12 seems equivalent to the keysend scheme outlined in my email. The
current design is based on BOLT12 because it has broader support. I think
others have pointed this out, but it would be useful to see a spec PR for the
AMP reusable invoice format rather than high-level API docs, otherwise (a) it’s
hard to evaluate using it for async payments and (b) it hasn’t gone through a
stage of garnering community feedback.
> one of my key takeaways was that: Trampoline payments are a critical part of
> any sort of async payment scheme.
100% agreed with this point and explanation; async payments are not very
interesting without trampoline.
> "invoice tunneling". The idea is that you force the receiver to reveal a
> unique secret bound to the invoice or payment attempt.
I would be interested to read more about this, it sounds like it’s thinking
along similar lines to Matt’s idea mentioned at the end of my email, which is
also outlined in the notes from an async payments meeting[1]. Though if it’s
HTLCs-based, then I don’t see how it would work without changes to the onchain
script format to commit to additional data, since you can’t change the
preimage(?).
Whether PoP is necessary or not seems like a separate discussion to me :p the
current HTLCs-based async payments plan does not have the PoP property anyway,
but it would be nice to have a plan for how we *could* have it in the future,
hence the research wishlist.
-Val
[1]:
https://docs.google.com/document/d/1X6Hap9Hi5qJ9a-XVXmLILol2cBcpXExutw6-adPLAb0/edit
------- Original Message -------
On Tuesday, January 10th, 2023 at 5:35 PM, Olaoluwa Osuntokun
<laol...@gmail.com> wrote:
> 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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
