Cezary Dziemian [ARCHIVE] on Nostr: đź“… Original date posted:2017-11-03 đź“ť Original message: Thank you very much for ...
đź“… Original date posted:2017-11-03
đź“ť Original message:
Thank you very much for answers. It is honor that you answered and it is
also very important for us in Poland. My friend is building Bitcoin ATMs
and off-course plan to use LN. BTW: In Poland a lot of people believe that
LN is the next big thing. We have huge pro-LN community and even have LN
whitepaper translated to polish.
So for 1.1 such scenario will not be possible?:
We have such network with such payment channel opened:
Hub A
/ \
Payer Merchant
\ /
Hub B
Hub A and Hub B belong to the same person, who will try to cheat us. Now
Payer try to send payment through Hub A to Merchant. Hub A updates HTLC
contract with Payer for this payment but never updates HTLC contract to
Merchant so payment cannot be processed and is "pending". Because payer see
that payment is pending, tries to make payment using Hub B based on the
same invoice. After Marchant reveals secret number to Hub B, Hub A also can
use it to steal funds from first pending payment.
2017-11-03 2:20 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> Somewhat, but not that low, because you still need a margin to turn
> around payments.
>
How big this margin would be? If we have crypto with 5 seconds block
confirmation time, how big such timelocks could be? I quess it is hard to
answer precisely, but could you give at least estimated value?
Best Regards,
Cezary
2017-11-03 12:25 GMT+01:00 Johan TorĂĄs Halseth <johanth at gmail.com>:
> 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/20171104/141ab6d5/attachment-0001.html>;
đź“ť Original message:
Thank you very much for answers. It is honor that you answered and it is
also very important for us in Poland. My friend is building Bitcoin ATMs
and off-course plan to use LN. BTW: In Poland a lot of people believe that
LN is the next big thing. We have huge pro-LN community and even have LN
whitepaper translated to polish.
So for 1.1 such scenario will not be possible?:
We have such network with such payment channel opened:
Hub A
/ \
Payer Merchant
\ /
Hub B
Hub A and Hub B belong to the same person, who will try to cheat us. Now
Payer try to send payment through Hub A to Merchant. Hub A updates HTLC
contract with Payer for this payment but never updates HTLC contract to
Merchant so payment cannot be processed and is "pending". Because payer see
that payment is pending, tries to make payment using Hub B based on the
same invoice. After Marchant reveals secret number to Hub B, Hub A also can
use it to steal funds from first pending payment.
2017-11-03 2:20 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> Somewhat, but not that low, because you still need a margin to turn
> around payments.
>
How big this margin would be? If we have crypto with 5 seconds block
confirmation time, how big such timelocks could be? I quess it is hard to
answer precisely, but could you give at least estimated value?
Best Regards,
Cezary
2017-11-03 12:25 GMT+01:00 Johan TorĂĄs Halseth <johanth at gmail.com>:
> 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/20171104/141ab6d5/attachment-0001.html>;