René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-10 📝 Original message: Hi, I am sorry to hear ...
📅 Original date posted:2021-07-10
📝 Original message:
Hi,
I am sorry to hear you had trouble with payment pathfinding. However if I
understand your suggestion correctly I think the proposed functionality
already exists in a very similar way in today's invoices with a mechanism
called fallback address. The main difference seems to be that the fallback
adress is not a human readable part of the invoice string but encoded with
the other data in the bech32 part of the invoice.
Check bolt 11 [1] on github for more detail but I copied the relevant
snippets from there to this mail.
- f (9): data_length variable, depending on version. Fallback on-chain
address: for Bitcoin, this starts with a 5-bit version and contains a
witness program or P2PKH or P2SH address.
The f field allows on-chain fallback; however, this may not make sense for
tiny or time-sensitive payments. It's possible that new address forms will
appear; thus, multiple f fields (in an implied preferred order) help with
transition, and f fields with versions 19-31 will be ignored by readers.
[1]:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
With kind regards Rene Pickhardt
<micaroni at gmail.com> schrieb am Sa., 10. Juli 2021, 07:56:
> Hi,
>
> I propose a new LN invoice pattern that contains a Bitcoin address for
> onchain transfer as backup.
>
> Motivation: My dream is to have an app wallet that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent to me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send it on-chain at XPTO fee rate? It can take a while."
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> <prefix>:<version>:<bitcoin address>:<invoice>
>
> Example:
>
> ln:v2:Hi,
>
> I propose a new invoice pattern that contains a Bitcoin address for
> onchain transfer.
>
> Motivation: My dream is to have a portfolio that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send onchain at XPTO rate?"
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> <prefix>:<version>:<bitcoin address>:<invoice>
>
> Example:
>
>
> ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj
>
> Thank you.
> _______________________________________________
> 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/20210710/f7e247db/attachment.html>;
📝 Original message:
Hi,
I am sorry to hear you had trouble with payment pathfinding. However if I
understand your suggestion correctly I think the proposed functionality
already exists in a very similar way in today's invoices with a mechanism
called fallback address. The main difference seems to be that the fallback
adress is not a human readable part of the invoice string but encoded with
the other data in the bech32 part of the invoice.
Check bolt 11 [1] on github for more detail but I copied the relevant
snippets from there to this mail.
- f (9): data_length variable, depending on version. Fallback on-chain
address: for Bitcoin, this starts with a 5-bit version and contains a
witness program or P2PKH or P2SH address.
The f field allows on-chain fallback; however, this may not make sense for
tiny or time-sensitive payments. It's possible that new address forms will
appear; thus, multiple f fields (in an implied preferred order) help with
transition, and f fields with versions 19-31 will be ignored by readers.
[1]:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
With kind regards Rene Pickhardt
<micaroni at gmail.com> schrieb am Sa., 10. Juli 2021, 07:56:
> Hi,
>
> I propose a new LN invoice pattern that contains a Bitcoin address for
> onchain transfer as backup.
>
> Motivation: My dream is to have an app wallet that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent to me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send it on-chain at XPTO fee rate? It can take a while."
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> <prefix>:<version>:<bitcoin address>:<invoice>
>
> Example:
>
> ln:v2:Hi,
>
> I propose a new invoice pattern that contains a Bitcoin address for
> onchain transfer.
>
> Motivation: My dream is to have a portfolio that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send onchain at XPTO rate?"
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> <prefix>:<version>:<bitcoin address>:<invoice>
>
> Example:
>
>
> ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj
>
> Thank you.
> _______________________________________________
> 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/20210710/f7e247db/attachment.html>;