> On Oct 19, 2021, at 04:51, Bastien TEINTURIER <bast...@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@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
