The Lightning network states that to send and receive BTC, both nodes must be online.
Some wallets, such as Phoenix, work as an independent node.
A proposal made by the former Bitcoin Core developer, Matt Corallo, tries to find a real solution to what would be a system for sending BTC on the Lightning network, without the need for the receiver to have its node connected to the network. and that, above all things, do not use custodial services.
The current protocol of the Bitcoin micropayment network, or Lightning network, states that, when sending funds, both nodes (receiver and sender) must be online. As Matt points out, on the Lightning-dev mailing list, there are multiple developments that try to mitigate this problem, but it seems they are not trying to find a real solution.
When sending a payment, the receiving node must be online, or, if it is from their mobile phone, they must have their mobile application open to receive the payment. This in a scenario where the user does not use third-party services, such as the WatchTower services, which monitors the status of the channel without the need for the user to be connected to the wallet.
Matt lists some of the “solutions” that are currently present in Lightning today that have improved the user experience, but have not found a real answer to this problem.
Among the solutions are, for example, services such as LNURL, which allows users to automatically generate multiple payment invoices (similar to a payment address in Bitcoin), without the need to create one by one manually. Which, although it is a service that improves the user experience on the Lightning network, is still an outsourced service, which could even be considered a custodian, since the maintenance of the LNURL server —which will generate the payment invoices from the user’s public key— is carried out by a third party.
Other solutions listed are AMP invoices, which generate a new payment invoice randomly every time the user requires it, which are already available in some clients of the Lightning network, as reported by . at the time.
Matt Corallo, has worked for Bitcoin Core since 2011, and currently works as a developer for the Square Crypto company. Source: Screenshot / Youtube.com
The solution to the problem
Corallo, in the first place, does not establish a definitive solution to the problem. Instead, it raises two things: to brainstorm or brainstorm, based on a possible solution, and that this can be considered as a “straw man” fallacy, which refers to the fact that the proposed solution may be oriented only to a part of the real problem, thus minimizing the real size of the problem in question. This clarification serves Corallo as a disclaimer on what can be interpreted from his proposal.
The basic solution that Corallo cites is in the use of CLTV, which are transactions in Bitcoin conditioned by time, that is, they are executed under the condition that a certain amount of time has elapsed or a certain block height has been reached in the chain.
A CLTV, in this case, for exchanges in the mode that the receiving node will be disconnected, would establish a longer time-out. The reason for this is to give you opportunity for the recipient to connect and verify that they have actually received the funds and be able to claim them.
However, this solution may be a bit archaic, so as an improvement, what would become PTLC could be used, an improvement on what would be HTLC, transactions on which the entire Lightining network is built. In this case, the PTLC would reach Lightning once Taproot is active in mid-November.
PTLCs may allow the user to use untrusted third party services in a secure manner. In this case, Corallo asked for suggestions for the use of PTLC in Lightning, once they are available in Bitcoin.