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
