Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-20 📝 Original message: > On Oct 19, 2021, at ...
📅 Original date posted:2021-10-20
📝 Original message:
> On Oct 19, 2021, at 04:51, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
> I like this proposal, it's a net improvement compared to hodling HTLCs
> at the recipient's LSP. With onion messages, we do have all the tools we
> need to build this. I don't think we can do much better than that anyway
> if we want to keep payments fully non-custodial. This will be combined
> with notifications to try to get the recipient to go online asap.
Thanks!
> One thing to note is that the senders also need to come online while
> the payment isn't settled, otherwise there is a risk they'll lose their
> channels. If the sender's LSP receives the preimage but the sender does
> not come online, the sender's LSP will have to force-close to claim the
> HTLC on-chain when it gets close to the timeout.
Yep. I was imagining a huge CLTV on that hop (and maybe some way of having a first-hop-set CLTV at hops after that, I don’t recall if it’s allowed, but it should be for this). That way at least the sender has a week/month to go online and clear the HTLC, subject to the usual LSP liquidity requirements of course.
> Definitely not a show-stopper, just an implementation detail to keep in
> mind.
>
> Bastien
>
>> Le jeu. 14 oct. 2021 à 02:20, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> a écrit :
>> Good morning Matt,
>>
>> > On 10/13/21 02:58, ZmnSCPxj wrote:
>> >
>> > > Good morning Matt,
>> > >
>> > > > The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to
>> > > > the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we
>> > > > just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl
>> > > > endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl
>> > > > endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately
>> > > > obvious to me that this is possible.
>> > > >
>> > >
>> > > Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.
>> > > You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).
>> >
>> > Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this
>> > without informing every hop along the path that this is going on, and adapting each hop to handle
>> > this as well. I suppose I should have been more clear with the requirements, or can you clarify
>> > somewhat what your proposed construction is?
>>
>> Just that: two hashes instead of one.
>> Make *every* HTLC on LN use two hashes, even for current "online RPi user pays online RPi user" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway.
>>
>> >
>> > If you're gonna adapt every node in the path, you might as well just use PTLC.
>>
>> Correct, we should just do PTLCs now.
>> (Basically, my proposal was just a strawman to say "we should just do PTLCs now")
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211020/27738a31/attachment.html>;
📝 Original message:
> On Oct 19, 2021, at 04:51, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
> I like this proposal, it's a net improvement compared to hodling HTLCs
> at the recipient's LSP. With onion messages, we do have all the tools we
> need to build this. I don't think we can do much better than that anyway
> if we want to keep payments fully non-custodial. This will be combined
> with notifications to try to get the recipient to go online asap.
Thanks!
> One thing to note is that the senders also need to come online while
> the payment isn't settled, otherwise there is a risk they'll lose their
> channels. If the sender's LSP receives the preimage but the sender does
> not come online, the sender's LSP will have to force-close to claim the
> HTLC on-chain when it gets close to the timeout.
Yep. I was imagining a huge CLTV on that hop (and maybe some way of having a first-hop-set CLTV at hops after that, I don’t recall if it’s allowed, but it should be for this). That way at least the sender has a week/month to go online and clear the HTLC, subject to the usual LSP liquidity requirements of course.
> Definitely not a show-stopper, just an implementation detail to keep in
> mind.
>
> Bastien
>
>> Le jeu. 14 oct. 2021 à 02:20, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> a écrit :
>> Good morning Matt,
>>
>> > On 10/13/21 02:58, ZmnSCPxj wrote:
>> >
>> > > Good morning Matt,
>> > >
>> > > > The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to
>> > > > the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we
>> > > > just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl
>> > > > endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl
>> > > > endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately
>> > > > obvious to me that this is possible.
>> > > >
>> > >
>> > > Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.
>> > > You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).
>> >
>> > Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this
>> > without informing every hop along the path that this is going on, and adapting each hop to handle
>> > this as well. I suppose I should have been more clear with the requirements, or can you clarify
>> > somewhat what your proposed construction is?
>>
>> Just that: two hashes instead of one.
>> Make *every* HTLC on LN use two hashes, even for current "online RPi user pays online RPi user" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway.
>>
>> >
>> > If you're gonna adapt every node in the path, you might as well just use PTLC.
>>
>> Correct, we should just do PTLCs now.
>> (Basically, my proposal was just a strawman to say "we should just do PTLCs now")
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211020/27738a31/attachment.html>;