Johan TorĂĄs Halseth [ARCHIVE] on Nostr: đź“… Original date posted:2017-11-03 đź“ť Original message: I think this might have ...
đź“… Original date posted:2017-11-03
đź“ť Original message:
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 <rusty at rustcorp.com.au> wrote:
Hi Cezary,
This is indeed the right place for such questions at the moment.
Cezary Dziemian <cezary.dziemian at gmail.com> 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
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/20171103/381678d3/attachment.html>;
đź“ť Original message:
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 <rusty at rustcorp.com.au> wrote:
Hi Cezary,
This is indeed the right place for such questions at the moment.
Cezary Dziemian <cezary.dziemian at gmail.com> 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
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/20171103/381678d3/attachment.html>;