Bitcoin is programmable money, and programmers, like life, find a way to respect the laws of nature but provide solutions. The Lightning Network is a new way to make payments using Bitcoin, but without the constraints of the primary blockchain. What this means for the average user is that instead of sending your Bitcoin to a single on-chain public address and then waiting for it to be confirmed, you can send smaller amounts all over the place with instant confirmations.
The Bitcoin Lightning Network has broken down many barriers for small payments, making eCommerce and in-person commerce a breeze (Not the Lightning wallet) and opening up new monetisation strategies like value for value and payment streaming.
Accepting Lightning payments alongside traditional payment channels can offer advantages for merchants in terms of lower operating costs, no fees paid to intermediaries, and instant access to the capital and this can all translate into lower prices at the till.
To get the gist of Lightning, you need to use it. It’s a pretty empowering feeling to send 0.00000001 BTC or one satoshi to another user in any part of the world and see the balance change instantly. Lightning shows a lot of promise, and people use it daily for commerce, remittance and simply to avoid paying chain fees.
The problem with Lightning is that you will run into issues when you’re dealing with emerging tech, and those that do have a bad experience feel that the entire project is a failure, not thinking how many times their fiat payments have failed or caused them issues, that had to be resolved by waiting for a call centre agent or standing in a bank queue.
The Lightning Network has been remarkably reliable, but sometimes there is an off-chance that these payments fail, and it’s because people need to understand precisely how they’re supposed to work.
In most cases, payment failure is a user error, but there is a small possibility it can be a network error.
So how do Lightning payments fail?
You have insufficient funds.
Let’s get the obvious one out of the way first; like any payment method, you can’t make the payment if you have no money. If someone sends you a Lightning invoice for 100 000 satoshis and you have 99 999 satoshis in your wallet, you will not be able to make the payment.
You would either need to top up your balance via Lightning, add additional funds from an on-chain wallet, open a new larger channel, or submarine swap on-chain funds for a larger Lightning network balance.
You don’t have channel capacity.
Lightning Network channels are dynamic tubes that route payments, limited firstly by the size of the channel and secondly by the inbound and outbound capacity avaialble in that channel. Due to the way Lightning is constructed and the current size of liquidity on the network, smaller payments have a higher probability of succeeding over bigger payments.
When you create a channel on the Lightning Network, it comprises two balances, your local and remote.
The funds that you own within the channel are called your sending capacity, local balance, or outbound capacity. These are the funds that are available to you to spend within this channel. When you send some coins to or through your counterparty, the amount that you send them is now up to the amount you can receive from or through them.
On the other end are the funds owned by your counterparty and called your receiving capacity, remote balance, or inbound capacity. These funds are available for your counterparty to spend within this channel. Your ability to receive coins depends on how many coins your counterparty has on their side of the channel to send you.
If the channel you’re using to pay or receive doesn’t have the capacity needed to route the amount, payments will fail, so it’s up to you to constantly rebalance channels to ensure they can always successfully route a payment.
There needs to be a path with liquidity.
In most cases, Lightning payments require a route with multiple hops to reach a user. If you do not have a direct connection with the node you wish to pay, you will be routing a payment between nodes until it reaches the destination. If there isn’t sufficient liquidity between the nodes to route this payment, it will fail.
In cases like this, you have two options:
- One would be to open a direct channel to the user you want to pay, but this only makes sense if this won’t be a one-time payment.
- The second would be to make the payment on-chain, where it might be cheaper and more reliable to route the payment.
In the future, combining Wumbo channels and multi-path payments might make these payment issues a thing of the past, and larger Lightning payments will be as reliable as the smaller ones are today.
You’re trying to pay an expired invoice.
BOLT11 invoices are the standard method of requesting payments on the Lightnin Network and probably the method you would use the most. One issue with the BOLT11 payment invoice is that it needs to be paid within a stipulated time since the Lightning invoice expires. When a wallet generates a BOLT11 invoice, it sets an expiry time frame, and depending on your wallet, it can have a default of 20 minutes to 24 hours or any time, for that matter.
Lightning BOLT11 invoices are designed for instant settlement, so the timing window makes sense for this type of payment request. If you do receive an invoice and it has expired, you will not be able to pay the user, and you will need to request a new invoice from the user to settle the payment.
You’re trying to pay with an unsupported format.
There are several ways of requesting payment on the Lightning Network. You can use a BOLT11 invoice (or QR Code format), an LN-URL (or QR Code), a Lightning Address or a BOLT12 invoice format. Depending on the wallet you’re using, you might have a wallet compatible with all these formats or one missing one or two, which can lead to some issues.
For example, if a user sends you a BOLT12 invoice, but your wallet isn’t BOLT12 compatible, your wallet will not be able to decode the information to relay the payment. The same applies to any of the other methods mentioned above.
Lightning wallets are working on adding all address formats, but until this is a uniform standard for all wallets, you will need to consider the request type for the moment.
A Lightning node is offline.
The Lightning Network requires users to always remain online to route payments and constantly update balances as payments are being routed. If a user’s node goes offline due to software failure, hardware failure, or no internet connection or electricity, that node is now unreachable, and their balances are frozen.
When a node you wish to pay is in a zombie state, it cannot update its balances; therefore, it cannot receive a payment, and your payment will fail.
Having to remain online constantly is only practical for some users, and missing out on payments is a double blow to the user who is now offline.
In instances where a user’s access to the internet or electricity is intermitted, you would need to opt for on-chain transactions since they only require a connection to broadcast the transaction.
For payments that are too small to move on-chain, there are solutions in the works, such as trampoline nodes that will hold payments until they can be routed, as well as other methods of asynchronous payments.
The Lightning Network isn’t final yet.
Lightning Network is still only four years old, meaning it’s not the final product. It’s being tested and developed in real time, and those who use it are providing valuable data for wallets, node operators and protocol developers.
The Lightning Network has come a long way since its first use on Bitcoin in January 2019, holding over 5000 Bitcion in publicly known channels across 17000 supporting nodes, but there are still some kinks to work out before the masses can jump onboard.
As issues are discovered, protocol issues are fixed, and payments on Lightning become more malleable and easier to route, it attracts more liquidity to channels. This provides a foundation that will encourage more users to move to Lightning, as users are more confident in the network as it offers a smoother and more reliable experience.
Do your own research.
If you want to learn more about Lightning, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
- Why Did My Lightning Network Payment Fail? – Failed Lightning Payments
- Lightning Payment failed (Could not find a route)
- Lightning Network Channel Capacity Explained
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.
