This is a somewhat long post, so I’ll give you the opportunity now to save yourself some reading time. Most of the post is historical context. If you are familiar with the history of bitcoin’s scaling debate, or are otherwise uninterested in my take on it, you can skip to the section at the end called “My conclusion”. If you’re like “damnit John just get to the point,” read the TL;DR at the bottom and you can read the rest of the post to fill in the details later.
I have been following the discussion around how to scale bitcoin since I first started researching the technology. I knew then as I do now that this will be the “make or break” debate for bitcoin, and also the most contentious given the challenges involved. I just did not know then how contentious it would be. Rather than solve the problem through hard forks or whatever other means necessary while bitcoin was small and relatively malleable, bitcoin grew very big, very fast, and the can has been repeatedly kicked down the road by developers and users to the point we are at today.
Even though it was obvious years ago that the only way bitcoin would reach global scale is through the widespread use of off-chain transactions, the systems needed to support such usage have only recently begun to be developed and none of any significance have yet been released in production. Thankfully, some forward-looking companies and bitcoin developers have been making the necessary investments to support such systems, including the Lightning Network and sidechains. Unfortunately, these systems are not ready yet, and the altcoins that have been nipping at bitcoin’s heel are now gnawing off its foot. There’s still a chance to save the rest of bitcoin and mend the wounds, but decisive action is needed, stat.
When I first gained an understanding of the issues at play in scaling bitcoin – mainly the effects on hashpower and full node centralization – I imagined that the off-chain technologies required to scale bitcoin would be ready by the time bitcoin hit its stride and gained mainstream adoption. I envisioned that there would be a graceful transition from on-chain to off-chain networks for daily “retail” usage. Not only has the transition not happened yet, when it does happen, it will hardly be considered “graceful”.
Due to various factors, bitcoin has gained a lot of attention recently. This has led to increased usage, and, subsequently, higher per-transaction fees. The average transaction fee today is about $1.00 USD. Just a year ago, it was less than $0.15. I am not opposed to high on-chain fees – in fact, I expect them to be at least 10x-20x higher or more in the future, and am completely ok with that. What I am opposed to is all bitcoin transactions being priced that high. Currently, users have no safe alternative if they want to transact in bitcoin. Either they swap IOUs on some trusted third party’s centralized database, or they pay $1.00 or more for every on-chain transaction. This isn’t the way it’s supposed to be.
Many of the decentralized “layer 2” off-chain solutions that have been proposed require slight modifications to bitcoin’s base “layer 1” protocol to work securely. One of the proposed modifications is called Segregated Witness (SegWit). While it’s not a scaling silver bullet, it paves the way for some exciting changes to bitcoin that will provide significant advancements for on-chain and off-chain scaling. Segregated Witness is not the only such proposal, but it is the one that has received the most attention and testing. And most importantly, it is production-ready today.
Despite a prior agreement to support SegWit, a large contingent of miners have failed to give it the support it needs to be activated on the main bitcoin network. The exact reasons that outspoken miners have given for their refusal to support SegWit activation vary, but the most common reason is that they won’t support SegWit unless a hard fork “non-witness” block size increase is bundled with it.
For various reasons, including concerns about the length of time it would take to test and safely deploy a hard fork, bitcoin developers have been unwilling to release a version of Bitcoin Core that would hard fork the network. They have presented several hard fork proposals for peer review, but none have yet gained the support required to merit merging into Bitcoin Core.
And so we have a stalemate.
After reviewing the arguments on all sides, and investigating nearly every scaling proposal put forward for public review, I have come to the conclusion that the miners should run SegWit software and signal for activation immediately, followed by a user-activated soft fork led by the economic majority when sufficient miner support is reached. Since signaling can be faked, a UASF will expose anyone who is swimming naked when the tide goes out (see: BIP66 fiasco).
If current holdout miners do not signal their support for SegWit, then the economic majority should still do a UASF, because the miners will quickly change their mind anyways (or else risk losing a lot of money). If the miners attempt to attack the UASF chain, then I will advocate for a transition away from double-SHA256 Proof of Work.
As stated earlier in this post, SegWit is the only proposal that has been rigorously examined and tested and put into production use by miners and full nodes. SegWit is being used in production by multiple altcoins, and to date there have been no bad incidents attributed to its deployment on these networks.
Additionally, SegWit does not preclude other on-chain scaling proposals, including non-witness block size increases. Given the nature of the anyone-can-spend hack, yes, we would (probably?) be locked into SegWit for the foreseeable future, but we can still layer other solutions on top – and there are a lot of great proposals that I would love to see tested and, if given a high safety rating, implemented in the future.
I have read and understand (to the extent possible given that I am not a software engineer) most of the reasons for opposing SegWit. Based on what I have read, heard, and have been told by engineers that I trust, the benefits of SegWit outweigh the costs. The developers that have spent time adding support for SegWit to their wallet and node software seem to agree. No other scaling proposal has such widespread support.
What’s important to understand is that SegWit is production-ready today, and any modification to include a hard fork or any other significant changes would simply delay scaling even further due to the time needed for testing and deployment. A hard fork requires an ecosystem-wide upgrade to go into effect, which takes time. A soft fork only requires miner support, and the SegWit soft fork is ready for activation today. We need scaling now, not in another six-to-twelve months.
Activate SegWit on bitcoin as soon as possible. Investigate other scaling solutions in parallel and implement the best of those later.
I realize that the debate has evolved from “what is the best way to scale bitcoin?” to “should Bitcoin Core continue to be the ‘reference implementation’ of the bitcoin protocol?” That question is outside the scope of this post and may be addressed in a future post. In any case, activating SegWit and changing the reference implementation are orthogonal issues; neither precludes the other.
Scaling Bitcoin series [link]
On Chain Scaling series [link]
Segregated Witness information [link]
ViaBTC: Why We Don’t Support SegWit [link]
Bitcoin miner: Why We Must Oppose Core’s SegWit Soft Fork [link]
Bitmain: Regarding Recent Allegations and Smear Campaigns [link]
Bitcoin Hard Fork Research [link]
Bitcoin Roundtable Consensus [link]
User-Activated Soft Fork (UASF) information [link]
BIP66 fork information [link]
A summary of the opposition to SegWit [link]
Bitcoin tips accepted:
Bitcoin address (what’s this?)
Bitcoin payment code (what’s this?)