March 6, 2016 at 12:24Brian Armstrong: urgent Bitcoin upgrade for 2 MB blocks
- Transfer
Posted by Brian Armstrong, CEO of Coinbase
Last year, I attended the Satoshi Roundtable conference with Charlie Lee and about 70 other members of the Bitcoin community.
I want to share my personal opinion about what happened at the conference (without disclosing names and content of private conversations).
There are many meetings between developers, miners and CEOs of bitcoin companies. As you know, now there is great disagreement about how to scale the Bitcoin system at the moment. On the one hand, there are kernel developers who worry that scaling the blockchain will affect decentralization. On the other hand, bitcoin companies that need system growth. Miners were, as it were, pinched from two sides, their opinions were divided.
I think the organizers of the conference hoped for some kind of consensus (as in Hong Kong), but by the end it became clear that the differences were too great. The discussion initially centered around what trade-offs could be made to temporarily solve the scalability problem. But as I discussed, this short-term solution worried me less and less, because I realized a more serious problem: the systematic risk for Bitcoin if Bitcoin Core is the only group working on the protocol .
There are a number of people with very high IQs in Bitcoin Core, but a few things really bother me after I spent some time with them last weekend.
Although the core developers say they agree to a hard fork of up to 2 MB (they have it in their plans, although in the distant future), but they refuse to make it a priority. They prefer to restrain decisions that can help the network right now, because they do not trust the community in the ability to make smart decisions in the future. They see themselves as the main architects of the network and advocates of people. They are ready to put up with the collapse of the Bitcoin network, if this does not contradict their basic principles.
Having a high IQ is not enough for success. You still need to make reasonable compromises, be friendly, communicate and be willing to cooperate. Any team that does not have such a desire will not be able to attract the best talents and will suffer in the long run. In my opinion, the main risk for the Bitcoin system now, ironically, is what has helped it in the past: kernel developers.
An interesting network failure scenario was discussed at the conference, which is troubling and shows how far we went.
The next halving of miners' rewards will occur in July. Suppose they spend on mining one coin, on average, $ 250 (this is a random figure). After reducing the fee, the cost of 1 BTC for them will increase to $ 500. If the price of bitcoin remains in the region of $ 425, then for many, mining will become unprofitable.
As a result, the processing power of the network may decrease in July. Perhaps by 10-50% (I don’t have a normal way to evaluate this, if anyone has one, let me know).
In the worst case, say, 50% of the hash computing power leaves the network due to unprofitability. This means that we start mining blocks every 20 minutes instead of 10 minutes. But now the blocks are already 70% full. If the average confirmation time drops to 20 minutes, then the blocks will be filled by 140%, that is, they begin to accumulate in the queue.
Bitcoin has a mechanism for regulating the complexity of proofs of proof when network power changes. This happens every 2016 blocks, which usually takes about two weeks. But we mine the blocks every 20 minutes, so it will take four weeks.
Everything is getting worse. Even four weeks later, until the complexity of the confirmations has changed, it will take another two weeks to process the accumulated queue until the network returns to “normal” indicators (70% coverage and periodic congestion). So you have to face a month and a half period when confirmations take two weeks, and the cost of transactions has dramatically increased. In addition, with so many pending transactions, the mempools of most nodes will be filled, most of the bitcoin transactions will probably not even be transmitted, so sellers and wallets will not receive transaction notifications within a few weeks.
If problems lead to a drop in Bitcoin prices, then mining will become even less profitable, and the vicious spiral will repeat.
It is not yet clear what the likelihood of the above scenario is (what I described as the worst case scenario). It is possible that with a decrease in mining rewards, the value of bitcoin will go up. And it is difficult to predict what percentage of hashing power can leave the network after reducing the reward. It can be much less than 50%. But I also think that there is no reason to take risks and it is incredibly irresponsible to play so close to the edge of the abyss. Even now, a network with 70% block coverage experiences problems with congestion and queuing. Any reduction in network power will exacerbate the problem.
The fact that the developers of Bitcoin Core brought the network to such a state speaks of their incredible negligence, and I think, in many ways, it shows their motivation and competence as a team. There is no reason to roll the dice and see if the worst case scenario comes true.
Fortunately, individual community members started talking about this two years ago and even left the Bitcoin Core team to write new code to increase network bandwidth. There is a way to avoid the problem.
It is worth noting that the Bitcoin Core team received an alternative solution to the scaling problem - the so-called Segregated Witness (SegWit) system.
Although this is a well-made technology, it seems risky to use this approach, given the situation described above. One of the main risks of using the new system is that it requires the introduction of new code not only at the kernel level, but also for every wallet provider that generates transactions. It is unlikely that this will be done in a short time and will avoid the scaling problems that threaten us. The number of lines of code that you need to write to all industry participants is several orders of magnitude greater than the number of lines of code to change the block size from 1 MB to 2 MB. The core developers were explained this at the conference, but they did not seem to change their minds regarding a short-term solution to the problem.
My general opinion (which I expressed at the round table last weekend) is that Bitcoin will be much more successful with many participants working on improving the protocol, and not with one team and their limitations that I spoke about. I think we can do it. In fact, we have to do this.
If you want to ensure the success of Bitcoin, I urge you to switch to Bitcoin Classic in the short term and then do everything you can to implement the three steps described above. This is the best way out of the dangerous situation in which we find ourselves.
In the future, it is necessary to form a new team to work on the Bitcoin protocol and help organize a “multiparty” system in order to avoid systematic risks for the kernel when only the team works on the protocol. Hopefully there will be good news in the coming months.
Last year, I attended the Satoshi Roundtable conference with Charlie Lee and about 70 other members of the Bitcoin community.
I want to share my personal opinion about what happened at the conference (without disclosing names and content of private conversations).
There are many meetings between developers, miners and CEOs of bitcoin companies. As you know, now there is great disagreement about how to scale the Bitcoin system at the moment. On the one hand, there are kernel developers who worry that scaling the blockchain will affect decentralization. On the other hand, bitcoin companies that need system growth. Miners were, as it were, pinched from two sides, their opinions were divided.
I think the organizers of the conference hoped for some kind of consensus (as in Hong Kong), but by the end it became clear that the differences were too great. The discussion initially centered around what trade-offs could be made to temporarily solve the scalability problem. But as I discussed, this short-term solution worried me less and less, because I realized a more serious problem: the systematic risk for Bitcoin if Bitcoin Core is the only group working on the protocol .
There are a number of people with very high IQs in Bitcoin Core, but a few things really bother me after I spent some time with them last weekend.
- Some of them demonstrate very low communication abilities or lack of maturity - this harms the ability to attract new developers to work on the Bitcoin protocol.
- They prefer "perfect" solutions, rather than "good enough." And if there is no perfect solution, then they put up with inaction, even if it puts the Bitcoin system at risk.
- It seems that they are convinced that Bitcoin is not able to scale well enough in the long run, and any block size in the future will be small, which they do not want to allow.
Although the core developers say they agree to a hard fork of up to 2 MB (they have it in their plans, although in the distant future), but they refuse to make it a priority. They prefer to restrain decisions that can help the network right now, because they do not trust the community in the ability to make smart decisions in the future. They see themselves as the main architects of the network and advocates of people. They are ready to put up with the collapse of the Bitcoin network, if this does not contradict their basic principles.
Having a high IQ is not enough for success. You still need to make reasonable compromises, be friendly, communicate and be willing to cooperate. Any team that does not have such a desire will not be able to attract the best talents and will suffer in the long run. In my opinion, the main risk for the Bitcoin system now, ironically, is what has helped it in the past: kernel developers.
Problems on the horizon
An interesting network failure scenario was discussed at the conference, which is troubling and shows how far we went.
The next halving of miners' rewards will occur in July. Suppose they spend on mining one coin, on average, $ 250 (this is a random figure). After reducing the fee, the cost of 1 BTC for them will increase to $ 500. If the price of bitcoin remains in the region of $ 425, then for many, mining will become unprofitable.
As a result, the processing power of the network may decrease in July. Perhaps by 10-50% (I don’t have a normal way to evaluate this, if anyone has one, let me know).
In the worst case, say, 50% of the hash computing power leaves the network due to unprofitability. This means that we start mining blocks every 20 minutes instead of 10 minutes. But now the blocks are already 70% full. If the average confirmation time drops to 20 minutes, then the blocks will be filled by 140%, that is, they begin to accumulate in the queue.
Bitcoin has a mechanism for regulating the complexity of proofs of proof when network power changes. This happens every 2016 blocks, which usually takes about two weeks. But we mine the blocks every 20 minutes, so it will take four weeks.
Everything is getting worse. Even four weeks later, until the complexity of the confirmations has changed, it will take another two weeks to process the accumulated queue until the network returns to “normal” indicators (70% coverage and periodic congestion). So you have to face a month and a half period when confirmations take two weeks, and the cost of transactions has dramatically increased. In addition, with so many pending transactions, the mempools of most nodes will be filled, most of the bitcoin transactions will probably not even be transmitted, so sellers and wallets will not receive transaction notifications within a few weeks.
If problems lead to a drop in Bitcoin prices, then mining will become even less profitable, and the vicious spiral will repeat.
It is not yet clear what the likelihood of the above scenario is (what I described as the worst case scenario). It is possible that with a decrease in mining rewards, the value of bitcoin will go up. And it is difficult to predict what percentage of hashing power can leave the network after reducing the reward. It can be much less than 50%. But I also think that there is no reason to take risks and it is incredibly irresponsible to play so close to the edge of the abyss. Even now, a network with 70% block coverage experiences problems with congestion and queuing. Any reduction in network power will exacerbate the problem.
The fact that the developers of Bitcoin Core brought the network to such a state speaks of their incredible negligence, and I think, in many ways, it shows their motivation and competence as a team. There is no reason to roll the dice and see if the worst case scenario comes true.
Fortunately, individual community members started talking about this two years ago and even left the Bitcoin Core team to write new code to increase network bandwidth. There is a way to avoid the problem.
What to do
- The first step is to immediately switch to 2 MB blocks. This is the most realistic short-term solution that will gain us time. I believe that we will either upgrade now (when everyone has enough time to prepare), or then we will have to do an emergency upgrade. There is code to solve this problem . High-quality code written by former core developers and already tested in production by many bitcoin companies (including Coinbase). An upgrade to Bitcoin Classic does not mean that we should stay on the Classic version forever, it's just the best option to eliminate the risks right now. In the future, we can use code from any group of developers.
- We need to establish a channel of communication with the Chinese miners about this upgrade. They were misled that only 4-5 people in the world can safely work on the Bitcoin protocol, although in fact it is this group that poses the greatest risk to their business. I will ask @cnLedger on Twitter to help translate this post into Chinese and help distribute it (update: it has already been translated ). We in the community need to build more ties with Chinese miners.
- In the long run, you need to form a new group for the development of the Bitcoin protocol. A team that will be friendly to new developers will be ready for reasonable compromises and which will help to continue scaling the protocol. We will hear about this in the next month or two.
It is worth noting that the Bitcoin Core team received an alternative solution to the scaling problem - the so-called Segregated Witness (SegWit) system.
Although this is a well-made technology, it seems risky to use this approach, given the situation described above. One of the main risks of using the new system is that it requires the introduction of new code not only at the kernel level, but also for every wallet provider that generates transactions. It is unlikely that this will be done in a short time and will avoid the scaling problems that threaten us. The number of lines of code that you need to write to all industry participants is several orders of magnitude greater than the number of lines of code to change the block size from 1 MB to 2 MB. The core developers were explained this at the conference, but they did not seem to change their minds regarding a short-term solution to the problem.
Conclusion
My general opinion (which I expressed at the round table last weekend) is that Bitcoin will be much more successful with many participants working on improving the protocol, and not with one team and their limitations that I spoke about. I think we can do it. In fact, we have to do this.
If you want to ensure the success of Bitcoin, I urge you to switch to Bitcoin Classic in the short term and then do everything you can to implement the three steps described above. This is the best way out of the dangerous situation in which we find ourselves.
In the future, it is necessary to form a new team to work on the Bitcoin protocol and help organize a “multiparty” system in order to avoid systematic risks for the kernel when only the team works on the protocol. Hopefully there will be good news in the coming months.