Chapter 6 of the book The Blocksize War is published below. The full book is available on Amazon. As a reminder, 50% of any profits from physical book sales will be donated to Médecins Sans Frontières, a charity that provides medical assistance to people affected by conflict, epidemics, disasters, or exclusion from healthcare.
The Blocksize War – Chapter 6 – Lightning Network
SegWit provided the option for users to create transactions that couldn’t be altered by malicious third parties (third party transaction malleability). This was considered a critical component for something called the lightning network, a layer-two scaling technology for Bitcoin. Without this fix, lightning would have been too complicated to implement.
The lightning network was first published in a paper from Joseph Poon and Thaddeus Dryja in February 2015. A few months later, a similar paper describing these layer-two solutions was published by Christian Decker.[1] The papers described the mechanics of a layer-two payment network on top of Bitcoin. Similar concepts had been discussed in the Bitcoin space for years. Indeed, the idea appears to have originated from Satoshi.[2] Lightning essentially works by aggregating multiple payments into a smaller number of Bitcoin transactions. Bitcoin transactions are used to open payment channels which, once set up, facilitate a flow of multiple payments. Entities can have channels with many different counterparties, forming a network of channels. Payments can then find a path along the channels, which are already directly connected to each other, until they reach the final recipient.
To some of the small blockers, this layer-two architecture made much more sense for a high capacity and cheap global payments system. On-chain, blockchain-based payment systems typically work in a “broadcast to everyone” mode, in that when one makes a payment, one needs to broadcast the transaction to all participants in the network. All participants are then required to process this transaction to see if it’s a payment to them. This system is considered highly inefficient, especially for small payments. If someone buys a coffee in France using Bitcoin, why should a merchant selling concert tickets in Japan need to examine that transaction? That is essentially how on-chain Bitcoin payments worked and, to the small blockers, the architecture made little sense for small payments; it was only needed as a base layer of a monetary system. The lightning network represents an improvement in efficiency and uses a more logical payment-network structure. Instead of broadcasting a transaction to everyone, the transaction can be sent more directly to the payment recipient, more of a peer-to-peer architecture. If one of the parties to the transaction is dishonest and tries to steal money, then the other party can broadcast a transaction to the Bitcoin blockchain and reclaim the funds. The blockchain, and Bitcoin’s proof-of-work consensus mechanism, is therefore used as a dispute resolution service. When both parties are honest, the nuances, inefficiencies and scalability constraints of the proof-of-work process can be avoided.
The main concern of the larger blockers was that lightning appeared to them to be used as an excuse or reason not to increase the blocksize limit. To them, this was highly inappropriate. The blocksize issue was a problem now, while the lightning network was highly complex, unproven and, in the best-case scenario, many years away from becoming usable. To the large blockers, Bitcoin was all about merchant adoption and 2015 had been a period of huge success. In 2015, Expedia, Overstock, TigerDirect, Newegg, Dell, Rakuten and Microsoft had all started allowing customers to pay with Bitcoin in one form or another. In April 2016, the video game store Steam had started accepting Bitcoin payments. These merchants were not using the lightning network, they were using on-chain transactions. If Bitcoin went down the lightning path, the payment solution these merchants had chosen would become unreliable due to high fees and long confirmation times. This would be a disaster for the network and the merchants would probably stop accepting Bitcoin and never return due to the bad experience. Although the lightning network had a technically superior architecture, this wouldn’t matter. Eventually, many of these merchants did stop accepting Bitcoin and the large blockers were proven largely correct. The phrase “don’t let the perfect be the enemy of the good” comes to mind. Not increasing the blocksize was clearly a bad business decision. Losing these merchants was a huge frustration to the larger blockers.
However, to the smaller blockers, Bitcoin was not a business, nor a payment system taking on VISA, Paypal and Mastercard. It was a new form of money, something far more ambitious and potentially far more transformational to society and the economy. It was taking on central banks. In general, small blockers had nothing against Bitcoin becoming a fast and cheap payment system; it just came second behind their main priority, which was a robust and new form of money.
This was not just a difference of opinion: to the small blockers, their priority was a smart strategic move, while the large blocker priority was naive. Bitcoin payments were fast and cheap compared to some other centralised forms of payments like credit cards and bank wires. However, if Bitcoin gains traction, these payment services can simply lower fees and speed up transaction times. Indeed, from an IT architecture point of view, there is nothing stopping this; the centralised payment networks are more efficient. Centralised IT systems are far more capable of processing more transactions, faster and at lower costs, than Bitcoin or any decentralised system. The reason these centralised payment systems had not done this was a lack of competition and some admin-related legal issues, which could be overcome. It was not because of some fundamental flaw in centralised database technology. If Bitcoin focused on being a low-cost payment network, which everyone recognised was a good thing, then sure it could gain market share in the short term; however, its advantage would prove to be unsustainable in the long run. In contrast, becoming a new form of money, capable of unblockable electronic transactions, was something the traditional financial establishment would be unable to compete with. This could therefore be the driver of long-term sustainable value. Again, this all appeared to come down to the same disagreement about time preferences.
To small blockers, the issue was not therefore a choice between a payment network and robust monetary system, with large blockers preferring the former and small blockers preferring the latter. It was that the fast and cheap payments network idea would not result in a model with a sustainable competitive advantage. Blockchain technology simply did not have the characteristics that made it suitable for this, it didn’t scale. The only way to effectively have both, they argued, was with a layer-two solution such as lightning.
With the lightning network being highly complex, this of course led to confusion, just as with SegWit. There were false claims that coins locked inside of lightning channels were subject to credit risk and claims that lightning would somehow make credit expansion on Bitcoin more of a problem. The high degree of complexity in lightning was certainly a problem, and there were valid issues and concerns. There was the question of how to ensure channels have sufficient liquidity to facilitate payments. There are transaction fees on lightning, which users need to pay in order to incentivise the provision of liquidity, and it is unclear if the dynamics exist such that this can scale effectively into a cheap, reliable payment network. The lightning network also had several other problems compared to on-chain Bitcoin payments, for instance it required the receiver of the transaction to be online and interact with the sender, something on-chain Bitcoin did not require. Lightning also requires users to monitor and manage their channels, to ensure they have sufficient liquidity and prevent theft from their channels. To the small blockers, these were real problems. However, in the long term these issues would eventually be hidden away from the user and third-party services or clever wallets would provide a solution using automated mechanisms. Again, it is about timing; these systems could take many years to develop and mature.
Large blockers could claim, with some legitimacy, that the small blockers were highly intelligent computer geeks biased towards complex, technically elegant, but impractical solutions. Small blockers were said to lack business acumen and could not see that a simpler solution to these issues was required. When it comes to lightning, this is one of the areas where, to date, large blockers have been shown to be mostly correct. At the time of writing, although the lightning network is gaining traction and the technology is rapidly improving, merchant adoption of the lightning network is limited. Merchant adoption of Bitcoin at the end of 2015 appears to have been more significant than lightning adoption today. However, I am still optimistic about the lightning network and, if one thinks decades ahead, success is still a possibility.
[1] https://link.springer.com/chapter/10.1007/978-3-319-21741-3_1
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002417.html