š
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>;
micaroni at gmail.com [ARCHIVE] /
npub183ā¦l5sgy
2023-06-09 15:03:05
in reply to nevent1qā¦r7mm
Author Public Key
npub183ws43p6p2yhlfv92evu5xg2wuj2g72qvzhqjmep8e37clf6ewnsrl5sgyPublished at
2023-06-09 15:03:05Event JSON
{
"id": "19e91250e32bc5b3092858117c179f09e133bec08827c23b71bac7244d077054",
"pubkey": "3c5d0ac43a0a897fa5855659ca190a7724a4794060ae096f213e63ec7d3acba7",
"created_at": 1686315785,
"kind": 1,
"tags": [
[
"e",
"7a4b907de880175668448e3d7a42debdc5338748cb8504a5916a0ed1337438d3",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2021-07-10\nš Original message:\nHi,\n\nI propose a new LN invoice pattern that contains a Bitcoin address for\nonchain transfer as backup.\n\nMotivation: My dream is to have an app wallet 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 to me, I had embedded a\nBitcoin address, the wallet could simply ask: \"Couldn't send via LN, do you\nwant to send it on-chain at XPTO fee rate? It can take a while.\"\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:v2:Hi,\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/01fd7239/attachment.html\u003e",
"sig": "8699bbacdd2139d3dad185f00dec31a5b6932e2cd372066f9daed2b8ee3bf09c6037aebfb65948278ced9528a88d4a24cc2f417e80fd2a29b6bcc943af8ad9ee"
}