Payment networks like Bitcoin are attractive targets for attack because they handle large sums of money and they transfer the bearer asset. If you can compromise a wallet or node and access the funds, there is no way of rolling back the chain, and those funds are lost forever. While the Bitcoin network itself has been pretty robust, the need to scale requires funds to move outside the chain consensus using different models.
Payment networks built on Bitcoin are making trade-offs in security to improve throughput, and that means new attack vectors that users of these networks need to face. That’s why these networks are constantly evolving, and new security measures are being developed all the time.
More speed means more risk.
Improved security increases the hurdles to attacking a network, and when users feel safer, they are willing to deploy more capital and hold it in these networks longer instead of moving to the base chain. The more capital in Bitcoin and second-layer networks, the larger the incentive to break them; as long as Bitcoin keeps increasing in wealth held and settled, it will always be an attractive target for attackers, and they will continue to look for loopholes to exploit.
Building an open-source payment network in the public eye at this scale has never been done before, and mistakes can be costly. No one’s code is perfect, and vulnerabilities in the implementation of payment networks like Lightning Network, if found, could lead to a quick payday for a malicious actor.
For example, in one case, an attacker was able to create balances out of thin air by abusing a quirk in how invoices were handled internally, such as channel jamming. This exploit has been patched in the latest versions, but similar vulnerabilities may exist in other Lightning applications.
Lightning is a communications protocol.
The Lightning Network is a method of moving Bitcoin from one user to another by updating one another’s balances through this second-layer network. When two users decide to anchor funds on the base chain and commit it to the Lightning Network, they pair up to create a peer-to-peer channel.
When a user transfers funds on Lightning, it can move to that peer as the final payment or use your connected peer as a step in the hop as you route payments along the network. To commit capital and keep balances up to date, Lightning Nodes needs to communicate with the wider network through the gossip protocol.
While the Lightning Network is designed to transfer Bitcoin, it is more of a communications protocol agnostic to the asset; in theory, you could use Lightning with other chains and assets, but Lightning running on other chains is a lot less secure.
To reduce strain on the network and spam the gossip protocol of the network, a Lightning channel imposes an upfront cost for channel creation, such as requiring a 2-of-2 transaction on the Bitcoin main network.
This ensures that attackers must spend real Bitcoin in transaction fees to create multiple channels, thus adding a tangible cost to advertising a channel.
Gossip has its limitations.
Gossip, which is the process of sharing channel information among nodes, plays a crucial role in maintaining an up-to-date understanding of the network’s state. However, gossip must be limited in scale due to bandwidth and processing limitations.
It is not feasible for billions of people worldwide to globally broadcast channel states frequently. Therefore, efforts are being made to reduce gossip requirements and explore alternative mechanisms for offloading route-making decisions.
Communicating false channels could be done through an alternative gossip network that has a different incentive mechanism in place to reduce the DoS vector.
What are fake lightning channels?
Fake Lightning channels refer to the creation of unbacked or non-existent payment channels in the Lightning Network. These channels are not backed by an on-chain UTXO and are created with the intention of deceiving other nodes on the network. The creation of fake channels is a potential Denial-of-Service (DoS) attack vector, as it can overwhelm other nodes that receive and rebroadcast gossip about these fake channels.
Nodes in the network rely on gossip, which is the exchange of information about channel states, to make routing decisions for payments. If a node receives announcements about fake channels, it would have to determine how many real channels already exist, which could lead to a split in the network as different nodes believe different sets of channels.
Efforts have been made to mitigate the risk of fake channels. However, proposals to limit the scale of gossip by reducing requirements for nodes and offloading route-making decisions to others come with trade-offs in privacy, reliability, censorship resistance, and potential centralisation.
What are the risks of fake lightning channels?
Fake channels are costless, so tens, hundreds or even thousands can be announced by a node to its peers, misleading them into believing that these channels exist and are available for routing payments. Malicious nodes can use a randomly generated funding transaction ID and sign a commitment transaction based on that fake ID.
This poses a risk as nodes rely on channel announcements to determine the network’s current state and make routing decisions.
Creating a fake channel can lead to a victim who successfully verifies the commitment signature against the provided (fake) funding outpoint, allocating resources for the fake pending channel. This can not lock up funds on the victim’s side, and funds would sit idle until the victim can close the channel.
How do we safeguard against fake lightning channels?
If you’re running a Lightning node, you should ensure you’re running the most up-to-date version of your preferred implementation. Lightning nodes released prior to the following versions are susceptible to a DoS attack involving the creation of large numbers of fake channels:
- Lightning Labs – LND 0.16.0
- Core Lightning – CLN 23.02
- eclair 0.9.0
- Lightning Development Kit – LDK 0.0.114
Relying on watchtowers
Another method of keeping fake channels at bay is through the help of watchtowers who keep track of channel states. If your lightning node is incapacitated by a DoS attack, a watchtower can keep a record of the channel state and allow you to issue a justice transaction to recover your funds. If you have significant funds at risk, it’s cheap insurance to run a private watchtower on a separate machine.
Do your own research.
If you want to learn more about Fake Lightning Channels, 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.