vwallace [ARCHIVE] on Nostr: đź“… Original date posted:2023-01-10 đź“ť Original message: Hi list! This email is a ...
đź“… Original date posted:2023-01-10
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/8bab4c04/attachment.html>;
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/8bab4c04/attachment.html>;