Scaling Bitcoin: Hong Kong Recap

While many were dubious that it would be successful, I attended the second Scaling Bitcoin workshop with high expectations. I’m pleased to report that a great deal of progress has been made and it looks like we have a number of clear paths laid out for how we can proceed with increasing the performance of the Bitcoin network so that it can support more users.

The most exciting announcement was made by Pieter Wuille about new advances made in the area of Segregated Witness. The short version is that Segregated Witness appears to help scale the Bitcoin protocol in a multitude of ways. It will enable us to:

  • Soft fork an effective block size increase to 3–4 MB by reducing on-chain transaction data sizes.
  • Fix transaction malleability, which is a major impediment to deploying the Lightning Network.
  • Deploy Bitcoin script language upgrades more easily.
  • Create compact fraud proofs so that lightweight clients can detect miner subsidy fraud.
  • Prune transaction signatures from historical blockchain data to further reduce total blockchain size by 60%.
  • Reduce bandwidth requirements for lightweight clients and for initial blockchain syncing.

I haven’t seen any opposition to this proposal and expect it will get fast tracked and deployed in the next 6 months, hopefully giving us enough breathing room for layer 2 scaling solutions such as Lightning Network to be deployed. It will also give us time to develop further scaling solutions such as IBLTs and Weak Blocks. Bitcoin needs to be scaled in a number of different ways — it’s going to require an ongoing effort to re-engineer every bottleneck.

Lightning Network is what I consider to be the next most exciting development. Tadge Dryja explained that there are several variants we may see, though given that Segregated Witness should be arriving soon, I expect we’ll see Lightning Level 3, the most performant variant.

The Lightning Network Scalability Matrix

There are currently at least three groups working on Lightning Network implementations and it’s still the early days — unsolved problems remain, such as how path discovery will work. I’m hopeful that by this time next year we will have a fairly functional Lightning Network, though it will probably be difficult for non-technical people to use. Once the underlying network is running solidly, then we should expect to see wallets and service providers to start tapping into it and enabling the average user to make use of the Lightning Network, hopefully without them even knowing what is happening behind the scenes.

We can also expect to see an increase in the speed at which the Bitcoin protocol can be upgraded via soft forks. At the moment, Bitcoin is limited to deploying soft forks serially, one at a time. However, BIP9 will enable us to deploy up to 29 new soft forkable features simultaneously.

There was also good news on the privacy front: Madars Virza gave a presentation about advances made in the area of zero knowledge proofs. Zero knowledge proofs can bring bulletproof anonymity to Bitcoin by severing the public links between transactions, making the flow of funds untraceable and yet still cryptographically proven to not be fraudulent.

I first wrote about Zerocoin in 2014, but have been disappointed that not much progress has been announced since then. Thus I was excited to hear that Zooko Wilcox and a team of engineers have joined the Zerocash team and plan on deploying an altcoin called Zcash. Zerocash has what was originally considered a showstopper of a flaw - it requires a trusted entity to conduct a one-time setup of the parameters of the system. During the setup procedure, secret random data is generated and used to compute the public parameters; the random data is then destroyed, and the parameters are broadcast. If done correctly, the system is secure from tampering. However, if the parameter creators retains the private data corresponding to the public parameters, the system would continue to provide anonymity guarantees, but it would be possible to forge fraudulent coins. I was pleased to hear that the Zcash team has developed a secure multiparty protocol for conducting the initialization. It uses a ring process such that only one party involved in the setup needs to delete their private data in order to break the ring and ensure that the full set of private data can’t be recreated and used to compromise the system. We can expect that the Zcash setup will involve a set of highly reputable individuals from the cryptography and security fields, practically ensuring that they will not collude to retain the private data.

Kalle Rosenbaum and Rusty Russell told us about advances in Invertible Bloom Lookup Tables and Weak Blocks, which will help blocks propagate through the network faster and reduce orphan rates. IBLTs were first proposed by Gavin Andresen in 2014. It turns out that IBLTs scale really well — the larger the block, the smaller the relative size of the IBLT needed. Kalle & Rusty have been building blocks from IBLTs with ~98% success rates.

Finding the sweet spot for IBLT size versus successful reconstruction rate.

The mining panel was fascinating. It was surreal to see a group of people on a single stage who represent a supermajority of Bitcoin hashing power. I was surprised by their neutrality — if anything, the miners generally don’t seem to want the responsibility of making protocol decisions — they defer to the Bitcoin developers. On the other hand, Bitcoin developers don’t want to be seen as central planners, which can lead to a stalemate. While we still don’t have consensus between miners and developers about a block size increase, they have agreed upon a set of metrics that should be used to judge block size proposals.

This tweet elicited many responses regarding centralization of mining. Yes, more mining decentralization is preferable; it’s one reason I support 21’s long-term vision for redecentralizing mining. But no, miners aren’t going to collude to censor Bitcoin — they’d be shooting themselves in the foot & wasting millions of dollars in capital investments.

The bigger centralization risk at the moment appears to be that the Chinese government could seize hardware amounting to 60% of the current hashing power in order to censor transactions. However, the risk of this occurring seems quite low — why hasn’t the government already done so if it cares? I don’t think that Bitcoin poses a sufficient threat to governments at this time, though this may very well change as the system grows.

I’m excited by the plethora of scaling proposals, though as I’ve stated in the past, we need scaling solutions so that we can support larger blocks. A hard fork to increase the block size will eventually be necessary if we want the network to support more users. I’ll close with the words of Jeff Garzik:

“A hard fork will signal that we’re willing to grow, that we’re willing to change, that we’re willing to change the system.”