Author: ecurrencyhodler 2019-08-14 18:05:26
Published on: 2019-08-14T18:05:26+00:00
A proposal was made for automated inbound liquidity with invoices on the Lightning Network. The problem addressed was waiting for inbound liquidity as a channel establishes when coming online and wanting to receive a LN payment. The solution proposed was embedding the node URI of the invoice creator, along with the amount to be routed. Scenario 1 involved Bob paying the invoice and the routing node opening a payment channel and pushing sats to the recipient, who could still make LN payments instantly through the routing node because the routing node just needs to wait until the 6 confirmations and settle all accounts after the fact. In scenario 2, Bob and the recipient knew each other, so if the channel disappeared, it was basically the same situation with Thor's instant channel. They could completely remove scenario 2 and only allow routing nodes to open channels to the recipient as long as Bob made the payment.A current and practical way to set up incoming liquidity was also suggested by taking some on-chain funds, creating a channel to a high-uptime node on the network (just run an autopilot), then using a submarine swap (i.e. pay off-chain funds to buy on-chain funds). Routing nodes who provide this service could charge a premium. The advantage of this approach is that it gives users control over what nodes they make channels with and would be a good investment in their future accessibility over the Lightning Network. However, this approach required on-chain funds. It was suggested that as a new business or merchant, one would have capital in some form before starting their business. The most sensible way to store and transport financial capital is Bitcoin, thus one already has what is needed to start this.
Updated on: 2023-06-02T20:04:36.305854+00:00