📅 Original date posted:2021-07-10
📝 Original message:
I'm sorry for the bad copy/paste in the last email. Resending:
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.
On Sat, Jul 10, 2021 at 2:55 AM <micaroni at gmail.com> wrote:
> 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/7c6e9821/attachment-0001.html>;
micaroni at gmail.com [ARCHIVE] /
npub183…l5sgy
2023-06-09 15:03:05
in reply to nevent1q…qcum
Author Public Key
npub183ws43p6p2yhlfv92evu5xg2wuj2g72qvzhqjmep8e37clf6ewnsrl5sgyPublished at
2023-06-09 15:03:05Event JSON
{
"id": "7602923654f31c6465a507868c724860ae39249f9c7ebc9f168f4dc4076e4548",
"pubkey": "3c5d0ac43a0a897fa5855659ca190a7724a4794060ae096f213e63ec7d3acba7",
"created_at": 1686315785,
"kind": 1,
"tags": [
[
"e",
"7a4b907de880175668448e3d7a42debdc5338748cb8504a5916a0ed1337438d3",
"",
"root"
],
[
"e",
"19e91250e32bc5b3092858117c179f09e133bec08827c23b71bac7244d077054",
"",
"reply"
],
[
"p",
"3c5d0ac43a0a897fa5855659ca190a7724a4794060ae096f213e63ec7d3acba7"
]
],
"content": "📅 Original date posted:2021-07-10\n📝 Original message:\nI'm sorry for the bad copy/paste in the last email. Resending:\n\nHi,\n\nI propose a new invoice pattern that contains a Bitcoin address for onchain\ntransfer.\n\nMotivation: My dream is to have a portfolio that works in a totally\nabstract and transparent way onchain and/or LN depending on the situation.\nPhoenix wallet almost achieves this, but there is still a certain\nLN/onchain distinction that confuses users a bit.\n\nI use Phoenix daily. Today, for some reason, I couldn't pay a friend.\nPayment failed in several attempts. It was not clear why. The fact is that\nI managed to transfer to Breeze and then from there I was finally able to\ntransfer to the final destination. For some reason it had no liquidity on\nthe specific route. These exception cases greatly confuse the most\nnon-expert users. If, on the invoice my friend sent me, I had embedded a\nBitcoin address, the wallet could simply ask: \"Couldn't send via LN, do you\nwant to send onchain at XPTO rate?\"\n\nThat way, in case of payment failure, there is an immediate onchain backup\nalternative, useful especially when rates are low, like now.\n\nThe format could be something like:\n\n\u003cprefix\u003e:\u003cversion\u003e:\u003cbitcoin address\u003e:\u003cinvoice\u003e\n\nExample:\n\nln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj\n\nThank you.\n\nOn Sat, Jul 10, 2021 at 2:55 AM \u003cmicaroni at gmail.com\u003e wrote:\n\n\u003e Hi,\n\u003e\n\u003e I propose a new LN invoice pattern that contains a Bitcoin address for\n\u003e onchain transfer as backup.\n\u003e\n\u003e Motivation: My dream is to have an app wallet that works in a totally\n\u003e abstract and transparent way onchain and/or LN depending on the situation.\n\u003e Phoenix wallet almost achieves this, but there is still a certain\n\u003e LN/onchain distinction that confuses users a bit.\n\u003e\n\u003e I use Phoenix daily. Today, for some reason, I couldn't pay a friend.\n\u003e Payment failed in several attempts. It was not clear why. The fact is that\n\u003e I managed to transfer to Breeze and then from there I was finally able to\n\u003e transfer to the final destination. For some reason it had no liquidity on\n\u003e the specific route. These exception cases greatly confuse the most\n\u003e non-expert users. If, on the invoice my friend sent to me, I had embedded a\n\u003e Bitcoin address, the wallet could simply ask: \"Couldn't send via LN, do you\n\u003e want to send it on-chain at XPTO fee rate? It can take a while.\"\n\u003e\n\u003e That way, in case of payment failure, there is an immediate onchain backup\n\u003e alternative, useful especially when rates are low, like now.\n\u003e\n\u003e The format could be something like:\n\u003e\n\u003e \u003cprefix\u003e:\u003cversion\u003e:\u003cbitcoin address\u003e:\u003cinvoice\u003e\n\u003e\n\u003e Example:\n\u003e\n\u003e ln:v2:Hi,\n\u003e\n\u003e I propose a new invoice pattern that contains a Bitcoin address for\n\u003e onchain transfer.\n\u003e\n\u003e Motivation: My dream is to have a portfolio that works in a totally\n\u003e abstract and transparent way onchain and/or LN depending on the situation.\n\u003e Phoenix wallet almost achieves this, but there is still a certain\n\u003e LN/onchain distinction that confuses users a bit.\n\u003e\n\u003e I use Phoenix daily. Today, for some reason, I couldn't pay a friend.\n\u003e Payment failed in several attempts. It was not clear why. The fact is that\n\u003e I managed to transfer to Breeze and then from there I was finally able to\n\u003e transfer to the final destination. For some reason it had no liquidity on\n\u003e the specific route. These exception cases greatly confuse the most\n\u003e non-expert users. If, on the invoice my friend sent me, I had embedded a\n\u003e Bitcoin address, the wallet could simply ask: \"Couldn't send via LN, do you\n\u003e want to send onchain at XPTO rate?\"\n\u003e\n\u003e That way, in case of payment failure, there is an immediate onchain backup\n\u003e alternative, useful especially when rates are low, like now.\n\u003e\n\u003e The format could be something like:\n\u003e\n\u003e \u003cprefix\u003e:\u003cversion\u003e:\u003cbitcoin address\u003e:\u003cinvoice\u003e\n\u003e\n\u003e Example:\n\u003e\n\u003e\n\u003e ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj\n\u003e\n\u003e Thank you.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/7c6e9821/attachment-0001.html\u003e",
"sig": "7ee5c3173b4ae6e204c03014e83296b81bdcbf48afed8eb5804b6e022ad1e7b8cfe618e1d059dd1628765c6a26bb9aff84b90583af02fe3fab2738bbf0d3fef6"
}