đź“… 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>;
Johan TorĂĄs Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:47:36
in reply to nevent1q…fa8w
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:47:36Event JSON
{
"id": "0150b3a0c0935e8435dd87e09d11b1d1525e30eab50c24b2ee93d910659aef80",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686314856,
"kind": 1,
"tags": [
[
"e",
"1d282530fe40601eac0b93f674e55b032fdd84f9a4e1ee7a7649cfac9ecfe8f7",
"",
"root"
],
[
"e",
"d78e4f949c786df53060d9656d64be88bc060a35d5dc00bb07192982a310b5a3",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2017-11-03\n📝 Original message:\nI 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?\n- Johan\n\nOn Fri, Nov 3, 2017 at 2:20, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\nHi Cezary,\n\nThis is indeed the right place for such questions at the moment.\n\nCezary Dziemian \u003ccezary.dziemian at gmail.com\u003e writes:\n\u003e 1. After LN starts, some group of users will use it, other not. If for\n\u003e example, I would like to receive payment for coffee from some user, I don't\n\u003e know if user uses LN or not. So, when someone buy something from me, do I\n\u003e need to ask him what kind of payment he would like to use (LN or on-chain)?\n\u003e The best would be, if I show him some qr code contains both public address\n\u003e and LN invoice and his wallet could choose how to pay. But this cannot be\n\u003e done this way, right?\n\nYes, the transition is kind of painful. You can use a BOLT 11 QR code,\nwhich can contain a fallback address, but that still requires their app\nunderstand BOLT11 enough to extract it.\n\nIf they understand the BIP70 payment protocol, it could include an\nalternate payment mechanism, but it seems nobody actually uses this.\n\n\u003e 2. Lets imagine, that someone send me invoice. I send payment and someone\n\u003e in the middle doesn't cooperate fast. My payment is waiting and until time\n\u003e lock period lapse I don't know if my payment will be processed or not. What\n\u003e to do then?\n\nThis is the worst case, yes. It's actually two cases: one where the\npayment has failed, and one where it has succeeded and you don't know\nyet.\n\nIf it's succeeded you'll get your goods (the recipient sees nothing\nwrong), so you don't care that you have to wait for the money to be\ndeducted.\n\nIf it hasn't, it's almost certainly going to fail, and you can either\nwait or try again with a new invoice (your wallet won't let to pay the\nsame one twice unless it's definitely failed). For 1.1 you'd be able to\nreuse the same invoice safely, as long as the merchant was honest if it\nreceived two payments and rejects the second.\n\n\u003e 3. Am I right that this decremental time lock is strongly related with\n\u003e block confirmation time? If there would be currency that have very fast\n\u003e confirmation time (like 5 seconds) then time lock period could be short\n\u003e what can potentially solve problem described in paragraph 2?\n\nSomewhat, but not that low, because you still need a margin to turn\naround payments. In practice, if payments are so unreliable that you\nhave to worry about this case, then something's horribly wrong!\n\nCheers,\nRusty.\n_______________________________________________\nLightning-dev mailing list\nLightning-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171103/381678d3/attachment.html\u003e",
"sig": "d7fc490d24f9716edae43d6e8ae91c7530e95cde92301e83b02b7a535d19d27a6d77d651d57e9f703a1dc761b79faef2f3867b527c4b6fa9f471ee04af74c1c8"
}