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 BTC sending system on the Lightning network, without the need for the receiver to have its node connected to the network. and that, above all, 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. According stand out Matt, 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, as is the case with the services of WatchTower, which monitors the channel status 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.
Solutions include, 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 CriptoNoticias at the time.
The solution to the problem
Corallo, in the first place, does not establish a definitive solution to the problem. Instead, come up with two things: brainstorm or brain storming, 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 about what can be interpreted from his proposal.
The basic solution that Corallo cites is in the use of CLTV, which are time-conditioned transactions in Bitcoin, 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 can 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.