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

2021-12-27 Thread Matt Corallo
On 12/2/21 21:59, Rusty Russell wrote: Matt Corallo writes: In bolt12, we have the additional problem for the tipping case: each invoice contains an amount, so you can't preprint amountless invoices. (This plugs a hole in bolt11 for this case, where you get a receipt but no amount!). However

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

2021-12-02 Thread Rusty Russell
Matt Corallo writes: > 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

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

2021-10-20 Thread Matt Corallo
> 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

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

2021-10-19 Thread Bastien TEINTURIER
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 w

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

2021-10-13 Thread ZmnSCPxj via Lightning-dev
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'

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

2021-10-13 Thread Matt Corallo
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

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

2021-10-13 Thread ZmnSCPxj via Lightning-dev
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, caus

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

2021-10-12 Thread Matt Corallo
On 10/12/21 22:08, Andrés G. Aragoneses wrote: 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 lig

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

2021-10-12 Thread Andrés G . Aragoneses
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

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

2021-10-12 Thread Matt Corallo
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 requi