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 <vwall...@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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
