micaroni at gmail.com [ARCHIVE] on Nostr: š Original date posted:2021-07-10 š Original message: Hi, I propose a new LN ...
š
Original date posted:2021-07-10
š Original message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/01fd7239/attachment.html>;
š Original message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/01fd7239/attachment.html>;