vwallace [ARCHIVE] on Nostr: đź“… Original date posted:2023-01-25 đź“ť Original message: Hey all, The research ...
đź“… Original date posted:2023-01-25
đź“ť Original message:
Hey all,
The research question still stands, but I wanted to issue a correction to this email –
> 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].
This is not true: if a regular PTLCs-based invoice generated by the receiver was given out multiple times by the receiver’s LSP, said LSP would not be able to steal the payment funds. This is because payers randomly tweak each hop’s point on every payment attempt, so the receiver’s LSP never learns the invoice’s original secret (unlike with HTLCs, where every hop learns the payment preimage). Further, the LSP would also need to know the sum of the aforementioned per-hop tweaks to steal, and they only know the tweak corresponding to their own hop. See this helpful PTLCs diagram from my teammate Arik: https://imgur.com/a/ZpdbYrt
Note that PTLC invoices when reused still do not provide PoP because the same secret would be revealed to every payer on every payment.
Thanks,
Val
------- Original Message -------
On Tuesday, January 10th, 2023 at 2:41 PM, vwallace <vwallace at protonmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230125/5b96b964/attachment.html>;
đź“ť Original message:
Hey all,
The research question still stands, but I wanted to issue a correction to this email –
> 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].
This is not true: if a regular PTLCs-based invoice generated by the receiver was given out multiple times by the receiver’s LSP, said LSP would not be able to steal the payment funds. This is because payers randomly tweak each hop’s point on every payment attempt, so the receiver’s LSP never learns the invoice’s original secret (unlike with HTLCs, where every hop learns the payment preimage). Further, the LSP would also need to know the sum of the aforementioned per-hop tweaks to steal, and they only know the tweak corresponding to their own hop. See this helpful PTLCs diagram from my teammate Arik: https://imgur.com/a/ZpdbYrt
Note that PTLC invoices when reused still do not provide PoP because the same secret would be revealed to every payer on every payment.
Thanks,
Val
------- Original Message -------
On Tuesday, January 10th, 2023 at 2:41 PM, vwallace <vwallace at protonmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230125/5b96b964/attachment.html>;