The Lightning Network is often heralded as the answer to Bitcoin’s scalability issues, enabling quick, low-cost transactions. Whenever the topic of bringing Bitcoin to more people comes up, especially those in the global south, you’ll hear the “use Lightning” response.
I was guilty of it myself, but we have to be honest about the state of the network so that expectations can be managed and the market can present constructive solutions.
Lightning does indeed solve a problem in onboarding the next cohort of Bitcoiners and does provide payment rails for cheap and efficient micropayments, but it is not without its trade-offs and limitations. There are certain aspects of Bitcoin that remain non-negotiable to change, regardless of the layer you’re using, aspects such as audibility, privacy and censorship resistance.
Lightning has a lot of potential, with plenty of upgrades and improvements in the pipeline. However, like any technology, it’s not immune to the potential for manipulation or misuse. One emerging concern is the potential for censorship on the Lightning Network.
Using Lightning fully non-custodially.
First, let’s get this out of the way if you’re using the Lightning Network on your own infrastructure by running a node and creating a private channel or pubic channel with a peer, you wish to route payments back and forth without the cost of touching the chain, you’re pretty safe from censorship. Especially when you know who the party is, you’re pairing up with and keeping your channels well-managed.
Anyone that acts hostile towards you can be trimmed from your network with a mutual or forced close, and you’ll have your channel balance returned to you on-chain.
The issue with the Lightning Network is very few participants are running their own nodes and managing their own channels because it can be cumbersome, requires technical knowledge and, at times, can be expensive.
The vast majority of Lightning Network users are
- Using a custodial wallet
- Using an exchange wallet
- Leveraging an LSP instead of their own node
- Running a cloud node
Once you start to bring in a trusted third party into your Lightning connection, you accept that for that convenience and cost saving; you’re giving up certain privileges; in most cases, that is through a loss of privacy and censorship resistance.
KYC wallets, LSPs, Cloud nodes and exchanges.
The simplest way to bring censorship to Lightning is to attack the custodial providers of the service and turn them into KYC chokepoints. Lightning Network wallets, exchanges, LSPs and Cloud Nodes could be forced to KYC their customers and add chain analysis to any UTXOs that enter their ecosystem.
This would effectively reduce the anonymity associated with Lightning transactions. Users could be deterred from using the network due to privacy concerns, reducing the user base and potentially limiting the network’s overall effectiveness and growth.
In this situation, your fallback options are to go the non-custodial route or find an LSP in another jurisdiction that would provide non-KYC services. Since the LSP is only relaying data, they can be hosted anywhere in the world, and you, as a user, could pick the LSPs that cater to you.
Connection to KYC Nodes Only
Another method of potential censorship involves limiting connections to only Know Your Customer (KYC) verified nodes. As a Lightning Network participant, who wishes to earn a yield or be a routing node, you need to find hubs where liquidity flows, so you can provide a connection for that hub and profit from that traffic.
There are obviously certain hubs like custodial wallets, exchanges and Lightning apps that generate more traffic and as a routing node, you want to be connected to those hubs.
Right now, it’s pretty much a free for all; if you have the required liquidity to open a channel with another peer, that’s all that you need. However, in this KYC scenario, users would only be allowed to open channels with nodes that have undergone KYC procedures.
This creates a barrier to entry, potentially stifling the openness and inclusivity that underpin the Lightning network. Requiring KYC verification to connect to certain nodes could result in the form of censorship and limit routing options for users.
Restricted vs Unrestricted Lightning Node Classification
Chain analysis is a scourage of the Bitcoin blockchain, as its main purpose is to track user transactions, reduce privacy and provide a basis for flawed censorship practices. As is the case with flagging UTXOs as tainted, Lightning service providers could be forced to first review UTXOs based on-chain analysis before creating channels or conducting submarine swaps.
Chain analysis could also be used to create a reputation system for nodes, and enterprise nodes might not be able to connect with nodes of a certain “risk factor.”
There could be a development of two classes of Lightning nodes – restricted and unrestricted. Restricted nodes might only form channels with other KYC-verified nodes, while unrestricted nodes could connect with anyone. This could lead to a form of network segregation, potentially impacting the network’s liquidity and the overall user experience.
Censoring traffic packets, UTXOs or any other metadata.
The Lightning Network’s off-chain nature makes it potentially more susceptible to censorship because it creates traffic hubs that can be targeted by governments. While the network and protocol cannot be affected, these Lightning liquidity hubs can be forced to add additional censorship practices.
For example, node operators could inspect or censor packet traffic, rejecting transactions based on their origination or destination. They could require routing to only go through certain nodes and exclude others from consideration. So users would be forced to connect to a certain KYC hub to communicate with another KYC hub and so on.
Governments could also force LSPs to limit the amount of funds a Lightning account can have, and how much it can route and flag any payments over a certain size or frequency.
However, this assumes that node operators have both the capability and desire to perform such actions, which may not be the case. All these restrictions not only add additional complexity and operating costs to the service provider, which will need to be reflected in their routing costs, but it also pushes away a certain cohort of privacy-conscious users.
If you’re losing customers due to privacy and pricing issues, other service providers are going to eat your lunch. The ability to remain competitive in Lightning and comply with government regulations is going to be a tough balancing act.
Forces that discourage censorship
Now that we know how Lightning can be censored in certain situations let’s look at how the network responds to these types of attacks and how it could discourage censorship.
Profit motive
Dealing with compliance is honourous, which requires LSPs to have a team and resources dedicated to reviewing transactions to remain compliant. Those additional costs will be reflected in the fees charged to use their service.
Additionally, when you’re limited to only connecting to certain nodes, hoping through certain channels and limits on what liquidity you can access, it only adds further costs to your operations that you either need to pay for from your margins or pass on to customers.
While the incentive exists for users to seek out the cheapest service provider and routes with the least honourous conditions to transfer funds, it doesn’t mean everyone will act upon it. If the fees for KYC lightning remain palatable for users, they might be willing to remain in these ecosystems, while those who don’t value privacy will not see the need to migrate.
Onion routing
The Lightning Network uses onion routing, which means each node in a chain of hobs will only know the node that was before it and the node that came after it. Therefore they can’t discriminate based on who is the sender or receiver of the transaction.
This does add complexity to tracking transactions and breaking up links between senders and receivers. However, Lightning clients need to know the network’s topology beforehand to pick a route, but managing each transaction manually to review routes would be a tough task. There would be a constant struggle to only share that information with some people and not others based on regulator requirements.
Blinded custody models
As LSPs are probably the primary attack vector and choke point for Lightning, LSPs could upgrade their service to provide blinded eCash mints for privacy-centric users.
An LSP could have KYC Lightning accounts for those who have to comply, such as businesses, but for the individual, they could migrate to using private options like Cashu or Fedi, which can interact with Lightning but provide LSPs with deniability.
Instead of offering users a Lightning account-based model where funds are seen and monitored, LSPs using eCash now have no idea who the user is, where the funds come from, what the transaction is for, where they are going or which mints are swapping between one another.
Incentives against censorship
The scenarios above outline potential avenues for censorship on the Lightning Network; it’s crucial to remember that these are theoretical possibilities and not current realities. But that doesn’t mean it should be ignored or not treated as a looming threat. Understanding potential threats to the core principles of Bitcoin is the first step in defending them.
As users of these payment rails, we should be aware of these possible pitfalls so we can manage our exposure and also protect ourselves against hostile actors in the future. As Bitcoin and the Lightning Network continue to grow and mature, maintaining their inherent properties of censorship resistance and privacy will remain key priorities and will be tested constantly.
The open-source nature of Bitcoin and its Lightning Network, coupled with the dedication of individual node runners and the vigilance of the developer community, is paramount in building alternative routes and keeping the topology of the network robust.
While developers can provide additional toolsets, it is up to the incentive structure of the network and the participant’s willingness to seek out these incentives. If a network has to rely on the goodwill of its user base, it will never have enough participants to survive large-scale attacks; altruism will only get you so far.
But economic incentives are far more appealing; they can be so compelling that they can even turn bad actors into supporters of your network. As we can see with mining, it’s far better to contribute hash rate and be rewarded than try to attack the network. This is a powerful incentive that holds up censorship resistance, and Lightning will need to figure out how it replicates this game theory.
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? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
