What Happened At The Satoshi Roundtable
Last weekend I attended the Satoshi Roundtable conference along with Charlie Lee and about 70 other members of the bitcoin community.
I wanted to share my personal opinion about what happened at the conference (without disclosing the names or content of any private conversations).
A number of meetings took place between core developers, miners, and CEOs of Bitcoin companies. As you’re aware, there is a large disagreement about how bitcoin should scale right now. On one side you have the core developers who have concerns about how on-chain scaling will impact decentralization. On the other side you have most bitcoin companies who want growth. The miners are sort of caught in between and are split.
I think the organizers of the conference were hoping for some sort of consensus (like what happened in Hong Kong), however it became clear by the end that the divide was too great. The conversations initially focused on various compromises to kick the can down the road on scalability. But as the conversations went on, I became less and less concerned about what short term solution we pick because I realized we all had a much bigger problem:the systemic risk to bitcoin if Bitcoin Core was the only team working on bitcoin.
The core team contains some very high IQ people, but there are some things which I find very concerning about them as a team after spending some time with them last weekend.
- Some of them show very poor communication skills or a lack of maturity — this has hurt bitcoin’s ability to bring new protocol developers into the space.
- They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.
- They seem to have a strong belief that bitcoin will not be able to scale long term, and any block size increase is a slippery slope to a future that they are unwilling to allow.
Even though core says they are ok with a hard fork to 2MB (they have it on their own roadmap, just very far in the future), they refuse to prioritize it. They prefer to withhold something that could help the network now, because they don’t trust the community to make educated decisions in the future. They view themselves as the central planners of the network, and protectors of the people. They seem ok with watching bitcoin fail, as long as they don’t compromise on their principles.
Being high IQ is not enough for a team to succeed. You need to make reasonable trade offs, collaborate, be welcoming, communicate, and be easy to work with. Any team that doesn’t have this will be unable to attract top talent and will struggle long term. In my opinion, perhaps the biggest risk in bitcoin right now is, ironically, one of the things that has helped it the most in the past: the bitcoin core developers.
Trouble On The Horizon
An interesting failure scenario was described at the conference that I think is troubling, and shows just how far things have gotten.
The next block reward halving is coming up in July. Let’s say that miners on average are able to mine a coin for $250 (I don’t know the exact number, so this is a guess). After the halving in July their cost to mine a coin will double to $500. If the bitcoin price stays around $425, it will be unprofitable for a number of miners to continue mining.
The implication of this is that we could see a reduction of hashing power on the network at the July halving date. Perhaps in the range of 10–50% (I don’t have a good way to estimate this, if anyone does please post it).
In a worst case, let’s say that 50% of hashing power turns off at the block halving because it is no longer profitable for those miners. This would mean that we start getting blocks mined every 20 minutes on average instead of 10 minutes. But blocks are already 70% full today. If the average confirmation time goes to 20 minutes, it means that we will be at 140% of capacity on every block, and start accumulating a backlog.
Bitcoin has a mechanism to adjust the difficulty of proof-of-work when hashing power changes. This happens every 2,016 blocks, which is normally about two weeks. But if we’re mining a block only every 20 minutes, then this will take four weeks.
It gets worse. Even after four weeks of being over capacity waiting for the difficulty to adjust, there is still up to another two weeks of backlog to churn through before getting back to “normal” (70% capacity and occasional delays). So you are looking at about a six week period of ~2 week confirmation times or drastically higher transaction fees. In addition, with so many pending transactions the mempools of most nodes will fill up, meaning it is likely that most bitcoin transactions will not even relay, much less confirm. This could prevent merchants and wallets from getting a notification about a transaction for weeks.
If this causes the bitcoin price to fall, it will make mining less profitable, and a negative spiral could happen.
It’s unclear what the likelihood is of the above scenario (admitedly, I’ve described a worst case scenario). With the new supply of bitcoin halving, this could also drive the price up. And it’s difficult to estimate what % of hashing power could turn off at the halving. It could be much less than 50%. But I also feel that there is no reason to risk it and it’s incredibly irresponsible to play things so close to the edge. The network today, with 70% of blocks full, is already experiencing congestion issues and backlogs. Any reduction in hashing power will exacerbate the problem.
The fact that bitcoin core has allowed the network to reach this point is incredibly negligent, and I think says a lot about their motivations and competency as a team. There is no reason to roll the dice and see if this failure scenario comes to fruition.
Luckily, voices of reason in the community have been calling for prudent capacity planning as far back as two years ago, and have even left the bitcoin core team to write the code to make it happen. There is a way we can avoid this.
A Path Forward
I believe we have a path forward to avert the scenario described above.
- The first step is that we need to do an immediate upgrade to 2MB blocks. This is the most realistic short term scaling solution that will buy us time. My belief is that we will either be doing this upgrade now (when there is sufficient lead time for everyone to prepare), or we will be doing it in the midst of an emergency down the road. It is not a matter of if, but when. There is code already available to accomplish this today. The code is high quality, is written by former core developers, and is already being run in production by a number of bitcoin companies (including Coinbase). By upgrading to BitcoinClassic it does not mean we need to stay with the Classic team forever, it simply is the best option to mitigate risk right now. We can use code from any team in the future.
- We need to communicate with the Chinese miners about this upgrade path. They have been misled to believe that only 4–5 people in the world can safely work on the bitcoin protocol, when in fact it is this group that poses the greatest risk for their businesses. I will be asking @cnLedger on Twitter to help translate this post and get the word out (Update: it is nowtranslated). We in the community need to do a better job building relationships with the Chinese miners.
- Long term, we need to form a new team to work on the bitcoin protocol. A team that is welcoming of new developers to the community, willing to make reasonable trade offs, and a team that will help the protocol continue to scale. You’ll be hearing more about this over the next month or two.
It is worth noting that bitcoin core’s response to scaling has been to propose a solution called segregated witness. While it is a well done piece of technology, I believe it would be quite risky to use segregated witness as a scaling solution given the situation mentioned above. One of the biggest risks of using segregated witness as a scaling solution (which was surfaced at the conference) is that to obtain the scaling benefit it will require not only new bitcoin core code, but also new code to be written by each of the major wallet providers who are generating transactions. It is unlikely this will be done in time to avoid the scaling issue we are currently facing. The number of lines of code that need to be written for this across the entire industry will be several orders of magnitude more than a scaling solution of changing 1MB blocks to 2MB blocks. This was explained to core developers at the conference and it didn’t seem to change their opinion of what the best short term solution was to scaling. Given the block halving arriving in July, and the fact that network delays are already being experienced on the network, my opinion is that it would be irresponsible and dangerous to follow the scaling roadmap proposed in the Hong Kong consensus at this point, which includes Segregated Witness.
Conclusion
My general view (which I articulated at the roundtable last weekend) is that bitcoin will be far more successful with a multi-party system working on protocol development than a single team with the limitations I mentioned above. I think we can make this happen. In fact, we must make this happen.
If you want to ensure Bitcoin’s success, I’d encourage you to upgrade toBitcoin Classic in the short term and then do what you can to help with the three step plan I outlined above. This is the best path forward to mitigate the dangerous situation we’ve found ourselves in.
In the future, we will need to create a new team to work on the bitcoin protocol and help bitcoin become a multi-party system to avoid the systemic risk of core being the only team working on the protocol. I hope to have an update for you on that in the coming months.
Common Questions/Criticisms
At the roundtable, here are the common arguments/criticisms I got against this line of thinking:
The market is uncertain because everyone is disagreeing, wouldn’t it be better if we all just put aside our differences and worked together?
It is difficult enough to get two people to agree. Three is harder, and four is even harder. Once a community gets to fifty or hundreds of people, getting everyone to agree is an irrational goal. But this is ok. Mechanisms exist to resolve disagreement amongst large groups of people (like voting). Waiting for everyone to agree is the same as saying that nothing will be done.
I gave the analogy of presidential elections in the United States. Getting Trump and Hilary supporters to all agree would be a fools errand. But elections happen and afterwards everyone stays in the same country even if one wins by a narrow margin. The system works. (Someone pointed out that people might move to Canada if Trump wins — while this is true, it will be far less than 1% of the U.S. population, which goes to further prove my point.)
I also gave the example of web browsers. The Chrome and Safari team are fierce competitors, but also attend the same conferences and collaborate with the IETF on standards. Many competing companies were present at the conference as well. They weren’t hostile or combative between each other. We are all working in the same industry and are friends in many ways. It would be the same with multiple teams working on the bitcoin protocol. By providing choice in the market you will get more progress, not less.
The market is uncertain now because it is like a country going through its first election. Once the first hard fork occurs successfully and multiple teams emerge, this will create confidence in the market because it shows bitcoin’s built in governance system is working (miner voting).
Bitcoin is different because it requires consensus rules — it would never work with multiple teams.
I don’t think this is correct. Different teams and implementations can each work on software that is interoperable and uses the same protocol (this is already true today in bitcoin). Upgrades or enhancements can be proposed by any team, but they won’t take effect until a majority threshold is reached. Bitcoin has a mechanism to resolve these disagreements: miner voting.
At the conference we spent a bunch of time discussing improvements to miner voting, including ways that users (or holders of bitcoin) could vote. There were some good proposals made about using “days destroyed” as a voting mechanism where users who generate transactions can signal readiness for an upgrade or a vote in favor of an upgrade. These are good ideas that I think should be explored further, but I think the exact implementation of how it can be done will be as controversial as any other major change in bitcoin, so it is unrealistic to wait on this becoming a reality given the looming scaling issues we have. We’ll need to upgrade to 2MB to buy ourselves some time before working out the details of this, and it will probably require a new team to build it that is less divisive in the community.
A 75% threshold is not sufficient to trigger an upgrade because the network will split!
I’ve discussed this at length elsewhere, but this is also false in my view. The economic incentives are aligned to have the vast majority (99%+) of miners, wallets, and exchanges end up on one fork. There is a big difference between the trigger threshold and what the ultimate majority will end up on.
Some people suggested that if I was sure about this, why not make the threshold 95% to be safe. There are a few problems with this.
When deciding a threshold you are balancing two things: upsetting a minority and the risk of deadlock. If you put it at 51% then the pro is that it is easier to resolve indecision amongst multiple parties, but the risk is that a large percentage of people get dragged along with something they don’t like. If you make a 95% threshold, then very few people get dragged along, but you risk never resolving conflict because it’s difficult to get 95% of people to ever agree on anything (again, imagine presidential elections). Put another way, it gives a 5% minority the right to veto any change that 95% of people want. Setting a 95% threshold is almost equivalent to saying “we’ll never change anything”.
I think Bitcoin Classic takes a very reasonable and balanced approach to this by setting a 75% threshold, and adding a 28 day grace period for people to upgrade once the threshold is reached. My guess is that this (or something close to it) will emerge as a standard for future protocol changes.
There are so few developers who understand the protocol that it would be dangerous to alienate the small handful of people who are working on it.
To answer this I tried to make the distinction between computer scientists (academic researchers working on crypto currency) and software engineers (people who build reliable, scalable software). There are probably a couple dozen qualified computer scientists working on crypto currency research right now, but there are at least tens of thousands of qualified software engineers in the world who are capable of building bitcoin protocol software. Google alone probably employs five or ten thousand of the latter. We’ve been able to build teams of engineers at Coinbase who can build scalable bitcoin node software, for example, as have several other companies in the space.
My hope is that many of the core developers continue to stay in bitcoin (some will quit, and that is ok). The industry needs both researchers and software engineers. But there is not a shortage of the latter.
In general, it should be obvious that Bitcoin will attract more smart people to work on it as a successful project than a struggling project.
I will also say that I think bitcoin core is part of the reason there are so few developers working on the protocol today. A common theme at the conference was people mentioning that bitcoin core has been unwelcoming, could use improved developer documentation, and has not produced a formal spec for the protocol to encourage other implementations.
The Bitcoin Classic team is not good enough to take over right now.
My argument here is that we are not asking them to take over. We should simply upgrade to the most reliable piece of software that will solve bitcoin’s current scaling challenge out of necessity. After that we can upgrade to software written by any team in the space (and I hope there will be more).
People also forget that the Bitcoin Classic code has been written and reviewed by former core developers (Gavin and Jeff). So I don’t agree with the quality argument, especially for this current release. Future releases we can judge independently. But their current scaling code is high quality, and that is all I’m advocating we use.
Bitcoin Classic is ready and being run in production today by a number of bitcoin companies. Bitcoin Core has produced no such option that is production ready, and seems committed to putting out sub-optimal solutions that I described above.
Long term we should focus on creating new teams, but at this point it would be irresponsible not to upgrade to Bitcoin Classic. We need to solve the immediate scaling issue we are facing.
Final Point
There continues to be rampant censorship onhttps://www.reddit.com/r/bitcoin regarding this debate, which is unfortunate. I continue to encourage everyone to move tohttps://www.reddit.com/r/btc as an alternative that is censorship free. Thank you.
https://medium.com/@barmstrong/what-happened-at-the-satoshi-roundtable-6c11a10d8cdf#.oqnx0nrud
