Author: ecurrencyhodler 2019-08-13 22:58:34
Published on: 2019-08-13T22:58:34+00:00
The email conversation discusses proposed solutions to the problem of waiting for inbound liquidity as a channel establishes when an individual first comes online and wants to receive a Lightning Network payment. One suggestion is to embed the node URI of the invoice creator, along with the amount to be routed, in the invoice. This way, Bob’s wallet sees an invoice + URI and automatically tries to route and open a channel + push 100,000 sat payment if it doesn’t see anything. The proposal allows for instant inbound liquidity to be automated via invoices. However, one email response raises concerns over connecting two end-users this way because if one mobile wallet goes offline, it locks the funds for the other part. Other suggestions include using the already existing fallback tag (`f`) on BOLT11 invoices, where you can embed a bitcoin address or setting up a "temporary" custodian channel if the receiver doesn't have enough inbound capacity. In this case, a third party custodian (i.e., the wallet provider) receives the money on your behalf. The benefits of automating inbound liquidity with invoices are that it would be non-custodial while offering almost the exact same experience. But automating inbound liquidity with push payments would make it instant as well as keep users on the LN. It is also possible to set shorter HTLC's for unilateral closures for specific channels. Although the proposals require certain specifics to be flushed out, they provide different approaches that could solve the problem of waiting for inbound liquidity as a channel establishes.
Updated on: 2023-06-02T19:51:08.273991+00:00