From r.pickhardt at googlemail.com Sat Jul 10 06:56:47 2021 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Sat, 10 Jul 2021 08:56:47 +0200 Subject: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address In-Reply-To: References: Message-ID: 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: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: