[Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

Bastien TEINTURIER bastien at acinq.fr
Tue Oct 19 11:51:38 UTC 2021


Hi Matt,

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.

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.

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/20211019/8844e3dc/attachment.html>


More information about the Lightning-dev mailing list