From lf-lists at mattcorallo.com Wed Oct 20 19:16:34 2021 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Wed, 20 Oct 2021 12:16:34 -0700 Subject: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User... In-Reply-To: References: Message-ID: <437490EA-1662-4279-9AFC-1A02A1F1570A@mattcorallo.com> > On Oct 19, 2021, at 04:51, Bastien TEINTURIER 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 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: