The Lightning Network is a second-layer environment for routing payments outside the restrictions of the bitcoin blockchain, which are known as that off-chain transactions. Transactions between parties are not on the blockchain but rather the updating of balances between members of the network who have decided to lock up bitcoin on-chain to allow them to be spent on the Lightning Network.
Multiple payment channels between parties or various bitcoin users make up the second layer and effectively form a web of payment pipelines for transactions to route through to their intended destination.
A Lightning Network channel is a two-party transaction method in which parties can make or receive payments from each other or allow third-party payments to route between them. This layer not only reduces the need to use the limited block space available on the primary bitcoin network, but it enhances the scalability of bitcoin and provides exciting use cases such as micropayments and streaming payments.
Lightning requires you to be online.
On the bitcoin main net, you do not need to be online to receive payment; as long as someone has a valid public address tied to your wallet, they can pay you by broadcasting a transaction to the network. In lightning, however, your funds need to remain active in a Lightning node with your keys active in a hot wallet.
The lightning network requires bi-directional payment channels between two nodes, which means that either one of those nodes should be able to initialise a transaction at any time. These transactions require both parties to actively participate in updating balances of the smart contracts that keep the channel alive. If one party fails to respond, they are essentially violating the smart contract and are forfeiting their claim to any of the funds in the channel.
Non-responsive clients are a liability to anyone opening up a channel. It means that their bitcoin may be tied up in the channel until the timeout period, and these zombie channels are a lag on the network’s routing capacity. An unresponsive node means the channel is wasted, and there is an opportunity cost in lost revenue for both parties.
Users who run Lightning nodes either do so to leverage the benefits such as cheap and instant payments or to earn network fees which are both actions that encourage remaining diligent in managing your node.
Now committing to being online 24 hours a day is one thing, but executing it is another. Lightning nodes could go offline for a range of reseasons such as:
- Failure of the device
- Updating your node
- An electricity shortage
- Unable to reach your node while you’re away
- Hard drive failure
If a user’s node is offline, it cannot route, send or receive payments, and any payments made during that downtime would fail, which isn’t a great user experience, which is why work on asynchronous payments is an essential addition to the Lightning stack.
How asynchronous payments bridge the gap
Currently, most Lightning users don’t see the need to commit resources to run a node and manage liquidity due to all the overhead required. They often seek third-party custodial services as their node backend or escrow payments to offline nodes.
Alternatively, Lightning users will opt for a custodial wallet solution since they only use it to route small payments. Should their balance get too large, they could submarine swap some of the balance to an on-chain wallet instead.
While these are workable options, the goal is to get more users to opt for the non-custodial route and expand the decentralisation of the Lightning Network.
Trampoline relay payments
One implementation of the Lightning Network, known as Éclair is exploring one of several proposals to reduce reliance on third parties to hold funds until the node returns online with a version of asynchronous payments. The new feature will enable sending funds over bitcoin’s most popular layer 2, even if a node is offline, such as a Lightning node on a disconnected node or a wallet tied to a disconnected node.
Eclair’s solution leverages a trampoline relay which would temporarily hold funds until a node restores its internet connection. These nodes might include devices that automatically sleep or any Lightning node with an unreliable internet connection or intermittent electricity.
Lightning Rod
Lightning Rod is another implementation by the team behind Breez wallet, which enables users to complete payments asynchronously. Lightning Rod works by the payee generating a preimage with a secret code and sending it to the payer.
Rod sends the payer a hash of the secret along with a HODL invoice containing the hash of the preimage he received from the payee. Using the hash of the secret, the payer can validate the payment source, meaning that the payer can validate the payment request that the payee initiated. And thanks to the HODL invoice, there’s no immediate settlement with Rod.
Offline Lightning payments are still a work in progress.
Thirdly, another option for async payments using Point Time Locked Contracts (PTLCs) is also in the works. PTLCs provide an alternative method for securing conditional payments by locking them with a public key and unlocking them with a corresponding signature once the node regains an internet connection. Developers say PTLCs will make conditional payments more private and take up less block space than an earlier hash-based proposal, HTLCs, which use hash digests and pre-images to lock and unlock payments.
PTLC’s offers less risk than trampoline relays do since trampoline relays will require a third party to delay forwarding the funds until the offline node can restore its connection. You can think of trampoline relays as a partial implementation of asynchronous payments that serve as a first step for getting it fully up and running.
Potential Issues with asynchronous payments
As is the case with bitcoin, there is no solution without trade-offs. While async payments provide a service that many bitcoiners will find helpful, it is not without its limitations. By offsetting the agreement of settlement between channel peers, async payments present a few issues that need to be considered by developers and users who would wish to use this method to receive payments in the future.
Wrong timelocks
If the timelock on the payment between Sally and Bob is longer than on the previous update transaction, Alice and Bob can steal money from Sally. If the payment between Sally and Bob is already initiated/ the money is locked up, Alice can publish the old update transaction on chain and close the channel with the old state.
If Bob waits/does not claim the payment before the timelock on the update transaction expires, Alice can settle the channel on chain with the old balance. Now Bob releases the signature to Sally and claims the payment, but because the channel is already settled and the signature is worthless.
Privacy
Sally currently knows both the sender and the receiver of the payment. If we split the payment from Sally to Bob into two payments between Sally and public routing node Pete and Pete and Bob by still using the same scalar + payment point, Sally only knows the sender, and Pete only knows the receiver.
Locked up capital
While Bob hasn’t yet claimed its money, the funds in the channel between Alice and Sally are essentially locked up. However, Alice and Sally could overwrite the payment (new update + settlement transaction). Alice could send multiple payments with the remaining balance, and before going offline, Alice would do the procedure again.
If Alice has sufficient inbound capacity in other channels, it can also re-balance its channel Alice-Sally so that the outbound capacity – (amt + fees) in this channel is zero and then do the procedure.
Communication channel
Obviously, the communication channel must be end-to-end encrypted. Otherwise, this is highly insecure. In this case, a decentralised and encrypted messaging system like Onion Messaging that is native to the Lightning Network and Nostr, which is compatible across all Lightning wallets and part of BOLT, could help improve privacy.
Do your own research.
If you want to learn more about asynchronous payments on bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research other sources, and you can start by checking out the resources below.
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? How do you handle channel rebalancing? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
