Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
It appears your example is of a bitcoin address embedded in a lighting uri, not the lighting invoice (unless it's serialized and I'm not seeing it) On Sat, Jul 10, 2021 at 5:10 AM Bitcoin Error Log wrote: > You can already embed a bitcoin address into an LN invoice. See example by > clicking “contribute” at https://thebiz.pro > > Looks like this: > > > bitcoin:bc1qfzaj2jaqhq7yn9hy3c00ndat4lq9me7sdvgc4q?lightning=lnbc50u1pswjc7ppp5qddlvfgk6j8aj3p9c3r7ql5j40yntv30ydcw77a6r8vvxmpf9uzsdrq235x2gzzd9azcgznv4shxmmwyqcjcgz9wp5hxmmyv5srxzjtwf5hxare94xx26t8dqsy66twv45xzms2yq34g3jnxqc52vpncqzpgfppqfzaj2jaqhq7yn9hy3c00ndat4lq9me7ssp5ftd8uqjrdrycugwmq0v868vk0zyu9gntrlla3chr74d83hkdz78s9qyyssqahk0vjzc0yfd3faevtsg0rx6guyyw6mnjmsyw858xtsqp3l4k763jhct4k7q5ndpc4mkznuskzj00vqql8vxlfp6n54kskkc8qheseqqf38kwg > > -- > ~ John Carvalho > > Schedule: https://calendly.com/bitcoinerrorlog > Chat: https://t.me/bitcoinerrorlog > Social: https://twitter.com/bitcoinerrorlog > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
You can already embed a bitcoin address into an LN invoice. See example by clicking “contribute” at https://thebiz.pro Looks like this: bitcoin:bc1qfzaj2jaqhq7yn9hy3c00ndat4lq9me7sdvgc4q?lightning=lnbc50u1pswjc7ppp5qddlvfgk6j8aj3p9c3r7ql5j40yntv30ydcw77a6r8vvxmpf9uzsdrq235x2gzzd9azcgznv4shxmmwyqcjcgz9wp5hxmmyv5srxzjtwf5hxare94xx26t8dqsy66twv45xzms2yq34g3jnxqc52vpncqzpgfppqfzaj2jaqhq7yn9hy3c00ndat4lq9me7ssp5ftd8uqjrdrycugwmq0v868vk0zyu9gntrlla3chr74d83hkdz78s9qyyssqahk0vjzc0yfd3faevtsg0rx6guyyw6mnjmsyw858xtsqp3l4k763jhct4k7q5ndpc4mkznuskzj00vqql8vxlfp6n54kskkc8qheseqqf38kwg -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
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 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: > > ::: > > 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: > > ::: > > Example: > > > ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqpq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqgq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj > > Thank you. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
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: ::: Example: ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqpq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqgq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj Thank you. On Sat, Jul 10, 2021 at 2:55 AM 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: > > ::: > > 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: > > ::: > > Example: > > > ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqpq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqgq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj > > Thank you. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
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: ::: 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: ::: Example: ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqpq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqgq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj Thank you. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
