Although I’ve been very critical of the Lightning Network, I feel it is very important for me to do extensive deep dives on the Lightning Network implementation as it exists circa October 2021. I believe this is essential because I want to be proven wrong. So far, my critics have rebutted my concerns using the following tactics:
Arguments from authority
This is the weakest type of argument especially for proponents of Bitcoin. This argument says, “This thing is true because certain people in the community who are generally considered reputable say its true, therefore it is true”.
Arguments by Deflection
This is also known as “what-about-ism”. “This thing is true because you don’t have any better ideas” or “I’ve heard your ideas and they are worse than my idea”. Good engineering stands on its own.
As you can see, I am in desperate need of real criticism. I’ve already learned a ton and resolved a good number of my own concerns about the Lightning Network. One could say that I’ve greatly expanded the shores of my own ignorance. I would like to publicly thank my friends, Mike C. and Darren N. for their feedback on complicated LN game theory.
As I get into the details about what I’ve learned, I would like to tell you how I am doing my research, so that you may also offer your feedback as I move forward with my research (yes, I am not done).
First, there is no substitute for actually running a Lightning Network node -and- actually competing to be a top 50 channel. I’ve done this and there is a lot to say about my experiences here. At this point, I’ll say that, financially-speaking, there are much easier ways to make profit either in the cryptocurrency world or just in the job market. But Ok, people like what they like. Running a successful LN node isn’t easy, my hat’s off to those competing day in and day out.
Second, there is absolutely no substitute for reading code and running a non-trivial simnet with multiple nodes. Simnet is the localized “simulation network” that anyone, developers, etc. can use to test out various scenarios in a tightly controlled, local-only environment. I am not claiming I fully researched EVERY implementation of the Lighting Network protocol; I focused on the lnd implementation connected to bitcoin core. I read and understand both C++ and Go, so this was the most convenient for me.
Third, I used Mastering the Lightning Network book to understand what topics are being presented to the Laity. Also, Andreas and his other authors have, historically, been pretty good at explaining why design decisions were made. Sometimes, it is difficult to get this context from the code. This book has not been officially released, so I will not hold the authors to anything that may be incorrect.
So let’s get into this. Allow me to tell you the items that I was WRONG about or at least was not chartable enough with respect to the Lightning Network.
First, I’ve made the claim that the LND nodes will make tons of money selling their users’ data. I am almost certainly WRONG about this as it stands in today’s LND implementation. The fact is, the LN community makes widespread use of the Tor network. So, when selecting a relay node to connect to, assuming relay nodes wish to remain anonymous, your selection criteria is limited to liquidity availability, uptime and number of payment channels. These relay nodes are limited to knowing what is being transmitted through their node (just like a Tor relay node). This is REALLY NICE. I hope this trend continues.
Second, as it stands now, the LN has not yet congealed into a functional hub and spoke topology. I am not saying I am wrong about this, but I will admit that I am not yet right about this either. There is steadily growing liquidity on the LN and this has brought in more relay nodes seeking to earn fees. I still believe that the eventuality will be that 80% of the bitcoin wallets transacting on the LN will be connected to 20% of the relay nodes. Popular relay nodes disproportionately bring in new payment channels (the Network Effect) because it will be cheaper and easier to find your payee. But, 20% of the wallets connecting to the remaining 80% of the relay nodes is not nothing, but if you are one of those relay nodes, there is very little incentive to keep operating long term. Chances are those nodes will turn off. It makes the most sense that wallet authors will direct their users to their own relay nodes by default. If you want to earn money on the LN, start by writing a popular bitcoin wallet.
You might be wondering why I haven’t criticized the Lighting Network on the same grounds as others in the space. The popular topics are pathfinding doesn’t scale and pathfinding just won’t work in all cases because it is NP hard (think Traveling Salesman problem). There is some truth to both of these objections, however, I am betting that that finding a path in a linear scenario just isn’t a problem. Please allow me to explain, if the LN becomes a logical hub and spoke like I project. The big nodes will have big payment channels between each other and the set of all possible routes to any possible payee will be relatively small. The big nodes will be very stable and all the nodes will not have a problem knowing where any individual payee is located. Likely, the changes in network topology will be adding new payment channels at the edge of the network similar to how to tree grows new leaves.
So, what are the remaining problems with the Lightning Network? The biggest issue is the Bitcoin mainnet itself.
Bitcoin mining fees have to simultaneously stay low enough to allow even the poorest among us to open at least one channel (and pray it never closes) -and- at the same time stay high enough to economically incentivize other people that they must use the LN for payments. Assuming the gap between the rich and poor, worldwide, keeps growing (and there is sufficient evidence that this will continue due to central bank policies), you now have a situation where the poorest cannot afford to open a single channel on the LN, let alone pay relay fees over time.
Bitcoin fees, not only have to stay relatively low, but they must remain stable to remove counterparty risk from LN invoice payments. Let me game theory this for you here:
Alice opens a payment channel with Bob for 100 sats.
They each build a commitment tx and Alice sends a funding tx to mainnet.
Alice pays Bob 50 sats, a new commitment tx is created and the previous one for 100 sats is revoked.
Alice decides to cheat Bob, so she broadcasts the previous (revoked) tx to Bitcoin mainnet. So she is attempting to receive all 100 sats, but she is only entitled to 50, Bob is entitled to the other 50.
Alice’s tx is perfectly valid in the absence of Bob’s disputing tx and penalty tx, but Alice must wait the pre-negotiated 2 weeks to spend away her 100 sats. Alice’s tx is mined, nonetheless. The clock is ticking for Bob.
Bob notices Alice’s deception and broadcasts his own penalty tx which states that he can receive ALL 100 sats because he can prove Alice is cheating. Great work, you are punishing the evil-doers.
The problem is that between the time that Alice’s tx was mined and the time that Bob broadcasts his penalty tx, the mainnet fees spiked and Bob can no longer afford the tx fees. He hopes and prays fees fall between now and the end of his check lock time verify period.
Worst case happens and fees never descend during this period and Bob is out the 50 sats.
This is an extreme edge case and, behaviorally, we can mitigate some of this risk, but it is a problem we all need to be aware of.
In subsequent articles, I will cover the risks of censorship on the Lightning Network and the pitfalls of private payment channels.