Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-13 📝 Original message: Hello Matt, can you ...
📅 Original date posted:2021-10-13
📝 Original message:
Hello Matt, can you clarify what you mean with this particular paragraph?:
But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
So the use case here is more narrow? You mean that the recipient is a
mobile user that has his phone locked?
Just so I understand better what the problem is.
On Wed, 13 Oct 2021 at 12:44, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> I'm sure most of y'all are familiar with this problem by now - a lightning
> user on a phone trying to
> pay another lightning user on a phone requires some amount of coordination
> to ensure the sender and
> recipient are, roughly, online at the same time.
>
> Invoices provide this somewhat today by requiring the recipient provide
> some live-ish data to the
> sender with their phone in their hand.
>
> But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
>
> There's a few things live today which make progress towards this goal, but
> don't quite get there
> (and mostly aren't trying to solve this problem, but are worth mentioning):
>
> * just have the recipient use a custodial product/run a full lightning
> node at home on an RPi.
> Obviously this has some pretty substantial drawbacks, I'm not sure I
> even need to list them, but
> the "just require the recipient use a custodial service" is what Twitter
> ended up shipping with for
> lightning tipping, and we should all probably feel ashamed that they felt
> the need to do that.
>
> * Blockstream Greenlight.
> This change the online-requirements model - with the keys on your
> phone/elsewhere you still have
> to have your phone online with the same requirements as running a full
> lightning node. It just means
> fewer resources on that device.
>
> * use keysend/AMP/whatever.
> This is great for tips, but only half the story. Sender goes to send a
> keysend payment, gets to
> one hop before the recipient, and then a day later the recipient comes
> online to find the payment
> long-since timed out and failed backwards. Or you could use a long CLTV on
> the payment to make sure
> the recipient has time to claim it, which is basically a DoS on the
> lightning network's capacity,
> one that may eventually be fixed, breaking your payments, and which is
> just generally antisocial.
> Still, my understanding is some folks do this today cause its the only
> option for a mobile device.
>
> * lnurl
> ...is a great way to get an invoice, presumably from a trusted LSP for
> the recipient, trusting
> them to not give the same invoice twice, but doesn't help the recipient
> receive the payment, they
> still need to be online, unless...
>
> * have a fully-trusted LSP that accepts payments and forwards them later
> this is also fine, where its practical, I guess, but I'd hope we can
> do better. Worse, as far as
> I understand the places where this is practical are becoming fewer and
> fewer as the regulatory
> uncertainty clears and everyone realizes the regulatory overhead of this
> is...well you might as well
> start applying for that banking charter now.
>
> * have an untrusted LSP that sends you a notification to open the app
> when a payment is received
> Several lightning apps do this today, and its somewhat of a stop-gap
> but does help. On platforms
> where the app gets some meager CPU time in response to a notification,
> this can even fully solve the
> problem by claiming the HTLC in response to the notification pushed
> out-of-band. Sadly, the refrain
> I've heard repeatedly is, these days, on both Android and especially iOS,
> you can't even rely on a
> microsecond of CPU time in response to a notification. The OS fully
> expects your app to run code
> only when its on and in the foreground, unless you're a VoIP app you're
> screwed. Relying on the user
> to open the app immediately when they receive a notification is...fine, I
> guess, absent a better
> idea it seems like the best we've got today, but I'm not sure you'd find a
> UX designer who would
> *suggest* this :).
>
>
> But what would it take to do better? What follows is a simple straw-man,
> but something that's
> borderline practical today and may at least generate a few ideas. It comes
> in two variants
>
> If we accept the lnurl trust model of "a third-party I can give a list of
> pre-signed invoices, which
> I trust to never provide an invoice twice, but otherwise is untrusted",
> then we could do something
> like this:
>
> Step 1. Tipper gets an invoice from the lnurl endpoint they wish to pay,
> which contains some
> "recipient is behind an LSP and rarely online, act accordingly" flag.
>
> Step 2. Tipper sender sends a HTLC with a long CLTV timeout to their own
> LSP with instructions
> saying "when you get an onion message telling you nonce B, forward this
> HTLC, until then, just sit
> on it". The LSP accepts this HTLC but does not forward it and is generally
> okay with the long CLTV
> delta because it would otherwise just be the users' balance anyway - if
> they want to encumber their
> own funds forever, no harm done.
> Note that if tipper is online regularly they can skip this step and
> move on.
>
> Step 3. The Tipper sends an onion message to recipient's LSP saying "hey,
> when recipient is online
> again, use the included reply path to send nonce B to my LSP".
>
> - sender can now safely go offline -
>
> Step 4. When the Recipient comes online, their LSP sends the reply to the
> Tipper's LSP,
>
> Step 5. causing the Tipper's LSP to (finally) forward the original HTLC,
> which the Recipient receives.
>
> You'll note that this solution, unlike simply sending a high-CLTV HTLC,
> does not encumber funds for
> any extended period of time except for the original sender, who wants to
> send the funds off
> elsewhere anyway. Nor does it rely on any parties who can at any point run
> away with the funds (or
> reasonably be construed as custodians for the funds). Further, this
> solution does not rely on the
> sender deanonymizing themselves to the recipient (or even informing the
> recipient who the senders'
> LSP is).
>
> Note that lnurl here could be replaced with BOLT 12 if BOLT 12 gets some
> flag indicating the Tipper
> should ask an LSP for the invoice.
>
> But, okay, so the lnurl model of a trusted party not reusing invoices so
> that the Recipient's LSP
> cannot just steal all funds after the first claim kinda really sucks, how
> do we do better?
>
> 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.
>
> Thanks to Steve for pushing on the "how does a let users get tips in
> lightning" issue, various
> people for giving him feedback and the relayed to me, AJ for the PTLC
> proposal, and Rusty for
> tireless drum-beating on onion messages and BOLT 12.
>
> Matt
> _______________________________________________
> 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/20211013/d180dac7/attachment.html>;
📝 Original message:
Hello Matt, can you clarify what you mean with this particular paragraph?:
But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
So the use case here is more narrow? You mean that the recipient is a
mobile user that has his phone locked?
Just so I understand better what the problem is.
On Wed, 13 Oct 2021 at 12:44, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> I'm sure most of y'all are familiar with this problem by now - a lightning
> user on a phone trying to
> pay another lightning user on a phone requires some amount of coordination
> to ensure the sender and
> recipient are, roughly, online at the same time.
>
> Invoices provide this somewhat today by requiring the recipient provide
> some live-ish data to the
> sender with their phone in their hand.
>
> But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
>
> There's a few things live today which make progress towards this goal, but
> don't quite get there
> (and mostly aren't trying to solve this problem, but are worth mentioning):
>
> * just have the recipient use a custodial product/run a full lightning
> node at home on an RPi.
> Obviously this has some pretty substantial drawbacks, I'm not sure I
> even need to list them, but
> the "just require the recipient use a custodial service" is what Twitter
> ended up shipping with for
> lightning tipping, and we should all probably feel ashamed that they felt
> the need to do that.
>
> * Blockstream Greenlight.
> This change the online-requirements model - with the keys on your
> phone/elsewhere you still have
> to have your phone online with the same requirements as running a full
> lightning node. It just means
> fewer resources on that device.
>
> * use keysend/AMP/whatever.
> This is great for tips, but only half the story. Sender goes to send a
> keysend payment, gets to
> one hop before the recipient, and then a day later the recipient comes
> online to find the payment
> long-since timed out and failed backwards. Or you could use a long CLTV on
> the payment to make sure
> the recipient has time to claim it, which is basically a DoS on the
> lightning network's capacity,
> one that may eventually be fixed, breaking your payments, and which is
> just generally antisocial.
> Still, my understanding is some folks do this today cause its the only
> option for a mobile device.
>
> * lnurl
> ...is a great way to get an invoice, presumably from a trusted LSP for
> the recipient, trusting
> them to not give the same invoice twice, but doesn't help the recipient
> receive the payment, they
> still need to be online, unless...
>
> * have a fully-trusted LSP that accepts payments and forwards them later
> this is also fine, where its practical, I guess, but I'd hope we can
> do better. Worse, as far as
> I understand the places where this is practical are becoming fewer and
> fewer as the regulatory
> uncertainty clears and everyone realizes the regulatory overhead of this
> is...well you might as well
> start applying for that banking charter now.
>
> * have an untrusted LSP that sends you a notification to open the app
> when a payment is received
> Several lightning apps do this today, and its somewhat of a stop-gap
> but does help. On platforms
> where the app gets some meager CPU time in response to a notification,
> this can even fully solve the
> problem by claiming the HTLC in response to the notification pushed
> out-of-band. Sadly, the refrain
> I've heard repeatedly is, these days, on both Android and especially iOS,
> you can't even rely on a
> microsecond of CPU time in response to a notification. The OS fully
> expects your app to run code
> only when its on and in the foreground, unless you're a VoIP app you're
> screwed. Relying on the user
> to open the app immediately when they receive a notification is...fine, I
> guess, absent a better
> idea it seems like the best we've got today, but I'm not sure you'd find a
> UX designer who would
> *suggest* this :).
>
>
> But what would it take to do better? What follows is a simple straw-man,
> but something that's
> borderline practical today and may at least generate a few ideas. It comes
> in two variants
>
> If we accept the lnurl trust model of "a third-party I can give a list of
> pre-signed invoices, which
> I trust to never provide an invoice twice, but otherwise is untrusted",
> then we could do something
> like this:
>
> Step 1. Tipper gets an invoice from the lnurl endpoint they wish to pay,
> which contains some
> "recipient is behind an LSP and rarely online, act accordingly" flag.
>
> Step 2. Tipper sender sends a HTLC with a long CLTV timeout to their own
> LSP with instructions
> saying "when you get an onion message telling you nonce B, forward this
> HTLC, until then, just sit
> on it". The LSP accepts this HTLC but does not forward it and is generally
> okay with the long CLTV
> delta because it would otherwise just be the users' balance anyway - if
> they want to encumber their
> own funds forever, no harm done.
> Note that if tipper is online regularly they can skip this step and
> move on.
>
> Step 3. The Tipper sends an onion message to recipient's LSP saying "hey,
> when recipient is online
> again, use the included reply path to send nonce B to my LSP".
>
> - sender can now safely go offline -
>
> Step 4. When the Recipient comes online, their LSP sends the reply to the
> Tipper's LSP,
>
> Step 5. causing the Tipper's LSP to (finally) forward the original HTLC,
> which the Recipient receives.
>
> You'll note that this solution, unlike simply sending a high-CLTV HTLC,
> does not encumber funds for
> any extended period of time except for the original sender, who wants to
> send the funds off
> elsewhere anyway. Nor does it rely on any parties who can at any point run
> away with the funds (or
> reasonably be construed as custodians for the funds). Further, this
> solution does not rely on the
> sender deanonymizing themselves to the recipient (or even informing the
> recipient who the senders'
> LSP is).
>
> Note that lnurl here could be replaced with BOLT 12 if BOLT 12 gets some
> flag indicating the Tipper
> should ask an LSP for the invoice.
>
> But, okay, so the lnurl model of a trusted party not reusing invoices so
> that the Recipient's LSP
> cannot just steal all funds after the first claim kinda really sucks, how
> do we do better?
>
> 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.
>
> Thanks to Steve for pushing on the "how does a let users get tips in
> lightning" issue, various
> people for giving him feedback and the relayed to me, AJ for the PTLC
> proposal, and Rusty for
> tireless drum-beating on onion messages and BOLT 12.
>
> Matt
> _______________________________________________
> 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/20211013/d180dac7/attachment.html>;