Rusty, your comments on BIP70 have me interested. Do you have a belief as to why it is not used? And I assume you are largely referring to the BIP 70-72 collection? Is it a case of App devs just not incorporating the functionality in?
On Fri, Nov 3, 2017 at 5:00 AM, < [email protected]> wrote: > Send Lightning-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lightning-dev digest..." > > > Today's Topics: > > 1. Re: Question: Invoice (Rusty Russell) > 2. Re: Question: Invoice (Johan Tor?s Halseth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 03 Nov 2017 11:50:19 +1030 > From: Rusty Russell <[email protected]> > To: Cezary Dziemian <[email protected]>, > [email protected] > Subject: Re: [Lightning-dev] Question: Invoice > Message-ID: <[email protected]> > Content-Type: text/plain > > Hi Cezary, > > This is indeed the right place for such questions at the moment. > > Cezary Dziemian <[email protected]> writes: > > 1. After LN starts, some group of users will use it, other not. If for > > example, I would like to receive payment for coffee from some user, I > don't > > know if user uses LN or not. So, when someone buy something from me, do I > > need to ask him what kind of payment he would like to use (LN or > on-chain)? > > The best would be, if I show him some qr code contains both public > address > > and LN invoice and his wallet could choose how to pay. But this cannot be > > done this way, right? > > Yes, the transition is kind of painful. You can use a BOLT 11 QR code, > which can contain a fallback address, but that still requires their app > understand BOLT11 enough to extract it. > > If they understand the BIP70 payment protocol, it could include an > alternate payment mechanism, but it seems nobody actually uses this. > > > 2. Lets imagine, that someone send me invoice. I send payment and someone > > in the middle doesn't cooperate fast. My payment is waiting and until > time > > lock period lapse I don't know if my payment will be processed or not. > What > > to do then? > > This is the worst case, yes. It's actually two cases: one where the > payment has failed, and one where it has succeeded and you don't know > yet. > > If it's succeeded you'll get your goods (the recipient sees nothing > wrong), so you don't care that you have to wait for the money to be > deducted. > > If it hasn't, it's almost certainly going to fail, and you can either > wait or try again with a new invoice (your wallet won't let to pay the > same one twice unless it's definitely failed). For 1.1 you'd be able to > reuse the same invoice safely, as long as the merchant was honest if it > received two payments and rejects the second. > > > 3. Am I right that this decremental time lock is strongly related with > > block confirmation time? If there would be currency that have very fast > > confirmation time (like 5 seconds) then time lock period could be short > > what can potentially solve problem described in paragraph 2? > > Somewhat, but not that low, because you still need a margin to turn > around payments. In practice, if payments are so unreliable that you > have to worry about this case, then something's horribly wrong! > > Cheers, > Rusty. > > > ------------------------------ > > Message: 2 > Date: Fri, 03 Nov 2017 12:25:46 +0100 > From: Johan Tor?s Halseth <[email protected]> > To: Rusty Russell <[email protected]> > Cc: [email protected] > Subject: Re: [Lightning-dev] Question: Invoice > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > I think this might have been discussed somewhere, sometime before: > couldn?t we add an lightning parameter to the bitcoin: url, making the QR > codes backwards compatible? > - Johan > > On Fri, Nov 3, 2017 at 2:20, Rusty Russell <[email protected]> wrote: > Hi Cezary, > > This is indeed the right place for such questions at the moment. > > Cezary Dziemian <[email protected]> writes: > > 1. After LN starts, some group of users will use it, other not. If for > > example, I would like to receive payment for coffee from some user, I > don't > > know if user uses LN or not. So, when someone buy something from me, do I > > need to ask him what kind of payment he would like to use (LN or > on-chain)? > > The best would be, if I show him some qr code contains both public > address > > and LN invoice and his wallet could choose how to pay. But this cannot be > > done this way, right? > > Yes, the transition is kind of painful. You can use a BOLT 11 QR code, > which can contain a fallback address, but that still requires their app > understand BOLT11 enough to extract it. > > If they understand the BIP70 payment protocol, it could include an > alternate payment mechanism, but it seems nobody actually uses this. > > > 2. Lets imagine, that someone send me invoice. I send payment and someone > > in the middle doesn't cooperate fast. My payment is waiting and until > time > > lock period lapse I don't know if my payment will be processed or not. > What > > to do then? > > This is the worst case, yes. It's actually two cases: one where the > payment has failed, and one where it has succeeded and you don't know > yet. > > If it's succeeded you'll get your goods (the recipient sees nothing > wrong), so you don't care that you have to wait for the money to be > deducted. > > If it hasn't, it's almost certainly going to fail, and you can either > wait or try again with a new invoice (your wallet won't let to pay the > same one twice unless it's definitely failed). For 1.1 you'd be able to > reuse the same invoice safely, as long as the merchant was honest if it > received two payments and rejects the second. > > > 3. Am I right that this decremental time lock is strongly related with > > block confirmation time? If there would be currency that have very fast > > confirmation time (like 5 seconds) then time lock period could be short > > what can potentially solve problem described in paragraph 2? > > Somewhat, but not that low, because you still need a margin to turn > around payments. In practice, if payments are so unreliable that you > have to worry about this case, then something's horribly wrong! > > Cheers, > Rusty. > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/ > attachments/20171103/381678d3/attachment-0001.html> > > ------------------------------ > > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > End of Lightning-dev Digest, Vol 27, Issue 2 > ******************************************** > -- Louis Willcock Software Developer Phone: 0422984471
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
