BitTorrent Lessons for Bitcoin
Bitcoin is currently having congestion issues, and is facing a political battle over said congestion. The same could have been said about BitTorrent starting around 2007. By 2010, in a spirit of cooperation between competitors, the pain rapidly began to fade. A similar spirit of cooperation can help Bitcoin today. This is a call for the developer community to help with wallet upgrades.
Around 2007 BitTorrent was in a tough spot. Comcast was actively fighting BitTorrent by breaking network connections. The politics of this bubbled up all the way to the FCC. Comcast was engaged in this battle because bulk BitTorrent traffic was slowing down the internet for all their customers. Users who were swapping files that might not even get watched were slowing down latency sensitive web users during peak times. This turned out to have a technical fix.
The root cause of the problem was due to the use of TCP. TCP treats all traffic the same. It doesn’t know the difference between high and low priority packets. It also can’t really tell how much available bandwidth there is. It uses packet loss as an indicator of congestion. When a loss is detected, all the TCP traffic through a bottleneck backs off, both high and low priority. Bandwidth usage slowly creeps back up until it bumps into the limit again. The solution was to treat BitTorrent traffic as lower priority, and back off much faster when congestion was detected. Thus was born uTP.
BitTorrent is not a single application. It is a diverse set of competing implementations. They all needed to survive in the face of a large powerful threat though. One of the more populist leaning development teams implemented a non-compatible protocol improvement. This was not a threat to the industry, because it only affected service for those who chose to run the populist client. The censorship from Comcast, however, affected the entire industry, not just a single implementation. BitTorrent, Inc. open-sourced the protocol implementation, but that wasn’t enough. Some implementations with smaller market share implemented uTP. However, this was a network effects problem. More clients needed upgrades to get the censors to back down.
Continuing to use TCP on most clients would continue the political battle with the censors. To save the industry, BitTorrent, Inc., lead by Bram Cohen stepped in to fund development of their competitors. A common library used by other clients was updated. In some cases, they directly paid competitors’ development costs. In return, they didn’t even get a thank you from the censors for saving millions in bandwidth costs and defusing a huge political fight. It is no longer common to hear about how some ISP is blocking BitTorrent, thanks to this.
The story of uTP is a great example of the industry cooperating to allay a menacing threat. Those with the resources available helped their direct competitors for the health of the protocol.
Wait, I thought this was about Bitcoin?
Bitcoin is having its own capacity problems right now. A technical solution is available, but it suffers a similar problem to BitTorrent. There are many competing wallets that need upgrading in order to take advantage of the SegWit capacity increase. Only a few wallets are currently supporting it. If the wallets do not actually create the new style transactions, then the extra capacity provided will be under-utilized. This sounds like a technical problem to me. If a fraction of the amount of energy being applied to modify consensus rules was devoted to upgrading wallets, then the available capacity of Bitcoin would be noticeably increased.
Lets take the top one on the list, Airbitz. Here is where SegWit can be implemented if you know C++. Are you a Java developer? Updating this code will give a capacity update for a huge share of blockchain.info wallet transactions. Do you prefer the iPhone and Objective C? Here is another huge market share of transactions that needs updating. None of these projects are working on SegWit right now, and Bitcoin would be much better off if they were.
It’s open source, and you can help.
I have floated this idea before with some Bitcoin developers. One objection I heard was the outside helpers might face some liability if their wallet improvement code went wrong. Thankfully, this industry celebrates contributions from anonymous developers.
As a counterpoint, in Bitcoin, code review is the bottleneck, not so much the development. Code reviews are harder to respect from anonymous people without reputations. Getting the code written is a large part of the battle though, and the community can certainly help there.
Even if all wallets upgrade to using SegWit transactions, this is only a short term bump in capacity, and everyone knows that. The argument over capacity will never end. Trade-offs in life exist, and optimizing for one thing diminishes the outcomes of another variable. Andreas has an analogy about how the internet capacity has also failed to scale from the beginning. With Bitcoin, adding capacity brings risks and induces shortcuts. When more transactions are using SegWit, protections against things like the quadratic complexity attack can be deployed. The MAX_BLOCK_BASE_SIZE & MAX_BLOCK_WEIGHT will be much less risky to raise. It might make sense to have weight fully supplant the current size and sigops limits. Having a single number determining cost will allow a diverse set of use cases. We can have a large but simple kickstarter transaction in one block, followed by compact but complex transactions in another. It would make it safer to re-enable the disabled op codes too. Raising subsets of the consensus limits (like just the max size) over time would merely put the capacity limitation on something else, like the sigops limit.
Lets move this process along by having fewer old-style transactions. The bottleneck is now with the wallets. Competent developers can make a difference now without running the gauntlet modifying the base protocol.
*Apologies for the gross simplification.
If you finished this article, this one is even better.