Brian Armstrong: we need an urgent Bitcoin upgrade to 2 MB blocks
Written by Brian Armstrong, CEO Coinbase
Last year, I attended the Satoshi Roundtable conference along with Charlie Lee and about 70 other members of the Bitcoin community.
I want to share my personal opinion about what was at the conference (without disclosing the names and content of private conversations).
')
There are many meetings between developers, miners and CEOs of Bitcoin companies. As you know, now there is a big disagreement about how to scale the Bitcoin system at the moment. On the one hand, there are kernel developers who are worried that blockchain scaling will affect decentralization. On the other hand, bitcoin companies that need system growth. Miner as it were pinched on both sides, their opinions were divided.
I think the conference organizers were hoping for some kind of consensus (as in Hong Kong), but by the end it became clear that the differences were too great. The discussion was originally conducted around which compromises can be made to temporarily solve the problem of scalability. But as we discussed this short-term solution, I was less and less concerned, because I realized a more serious problem: a systematic risk for Bitcoin, if Bitcoin Core is the only group working on the protocol .
There are a number of people with very high IQ in Bitcoin Core, but a few things worry me a lot after spending some time with them last weekend.
Although the kernel developers say they agree on a hard fork of up to 2 MB (they have it in the plans, although in the distant future), but they refuse to make it a priority. They prefer to hold back decisions that can help the network right now because they don’t trust the community to make informed decisions in the future. They see themselves as the main network architects and advocates of the people. They are willing to accept the collapse of the Bitcoin network, if this does not contradict their basic principles.
Having a high IQ is not enough for success. You also need to make reasonable compromises, be benevolent, 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 term. In my opinion, the main risk for the Bitcoin system now, ironically, is what helped it in the past: kernel developers.
The conference discussed an interesting network failure scenario, which is disturbing and shows how far we have come.
The next halving of miner remuneration will occur in July. Suppose they spend on mining one coin, on average, $ 250 (this is a figure offhand). After reducing the remuneration, the cost of 1 BTC for them will increase to $ 500. If the bitcoin price stays around $ 425, then mining will become unprofitable for many.
As a result, the computing power of the network may decrease in July. Probably 10-50% (I do not have a normal way to evaluate it, if someone has it, let me know).
In the worst case, say, 50% of the calculation power of the hashes leave the network due to unprofitability. This means that we begin to mine blocks every 20 minutes instead of 10 minutes. But now the blocks are already filled by 70%. If the average confirmation time drops to 20 minutes, the blocks will be filled to 140%, that is, they start to accumulate in the queue.
In Bitcoin, there is a mechanism for regulating the complexity of evidence (proof-of-work) when the capacity of a network changes. This happens every 2016 blocks, which usually takes about two weeks. But we mine blocks every 20 minutes, so it takes four weeks.
Everything gets worse. Even after four weeks, 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” performance (70% coverage and periodic congestion). So, we will have to face a one and a half month period, when confirmations take two weeks to complete, and the cost of transactions is drastically increased. In addition, with such a large number of pending transactions, the memory of most of the nodes will be filled, probably most bitcoin transactions will not even be transferred, so sellers and wallets will not receive transaction notification within a few weeks.
If problems lead to a fall in Bitcoin prices, then mining will become even less profitable, and the vicious spiral will repeat.
It is not yet clear what the probability of the above scenario is (what I described as the worst scenario). It is possible that with a decrease in the mining remuneration, the cost of bitcoin will go up. And it is difficult to predict what percentage of hashing capacity can leave the network after the remuneration decreases. 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 is experiencing problems with congestion and queue. Any reduction in network capacity 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 shows their motivation and competence as a team. There is no reason to roll the dice and see if the worst case scenario comes to life.
Fortunately, some members of the community 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 problems.
It is worth noting that the Bitcoin Core team received an alternative solution to the problem of scaling - the so-called “segregated Witness” system (SegWit).
Although this is a well-made technology, it seems to me risky to use this approach, given the situation described above. One of the main risks of using a new system is that it requires the implementation of a new code not only at the kernel level, but also with each purse provider that generates transactions. It is unlikely that this will be done in a short time and will allow you to avoid problems with scaling that threaten us. The number of lines of code that all industry participants need to write by several orders of magnitude exceeds the number of lines of code to change the block size from 1 MB to 2 MB. The kernel developers explained this at a conference, but they didn’t seem to change their mind about a short-term solution.
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, which I talked about. I think we can do it. In fact, we have to do it.
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 possible to implement the three steps described above. This is the best way out of a dangerous situation in which we find ourselves.
In the future, we need to form a new team to work on the Bitcoin protocol and help organize a “multi-party” system in order to avoid systematic risks for the kernel when only the team is working on a protocol. I hope this will be good news in the coming months.
Last year, I attended the Satoshi Roundtable conference along with Charlie Lee and about 70 other members of the Bitcoin community.
I want to share my personal opinion about what was at the conference (without disclosing the names and content of private conversations).
')
There are many meetings between developers, miners and CEOs of Bitcoin companies. As you know, now there is a big disagreement about how to scale the Bitcoin system at the moment. On the one hand, there are kernel developers who are worried that blockchain scaling will affect decentralization. On the other hand, bitcoin companies that need system growth. Miner as it were pinched on both sides, their opinions were divided.
I think the conference organizers were hoping for some kind of consensus (as in Hong Kong), but by the end it became clear that the differences were too great. The discussion was originally conducted around which compromises can be made to temporarily solve the problem of scalability. But as we discussed this short-term solution, I was less and less concerned, because I realized a more serious problem: a systematic risk for Bitcoin, if Bitcoin Core is the only group working on the protocol .
There are a number of people with very high IQ in Bitcoin Core, but a few things worry me a lot after spending some time with them last weekend.
- Some of them show very low communication skills or lack of maturity - this hurts the ability to bring new developers to work on the Bitcoin protocol.
- They prefer "ideal" solutions, rather than "good enough". And if there is no perfect solution, then they put up with inaction, even if it puts Bitcoin at risk.
- They seem to be convinced that Bitcoin cannot scale well enough in the long run, and any block size will be small in the future, which they don’t want to allow.
Although the kernel developers say they agree on a hard fork of up to 2 MB (they have it in the plans, although in the distant future), but they refuse to make it a priority. They prefer to hold back decisions that can help the network right now because they don’t trust the community to make informed decisions in the future. They see themselves as the main network architects and advocates of the people. They are willing to accept the collapse of the Bitcoin network, if this does not contradict their basic principles.
Having a high IQ is not enough for success. You also need to make reasonable compromises, be benevolent, 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 term. In my opinion, the main risk for the Bitcoin system now, ironically, is what helped it in the past: kernel developers.
Problems on the horizon
The conference discussed an interesting network failure scenario, which is disturbing and shows how far we have come.
The next halving of miner remuneration will occur in July. Suppose they spend on mining one coin, on average, $ 250 (this is a figure offhand). After reducing the remuneration, the cost of 1 BTC for them will increase to $ 500. If the bitcoin price stays around $ 425, then mining will become unprofitable for many.
As a result, the computing power of the network may decrease in July. Probably 10-50% (I do not have a normal way to evaluate it, if someone has it, let me know).
In the worst case, say, 50% of the calculation power of the hashes leave the network due to unprofitability. This means that we begin to mine blocks every 20 minutes instead of 10 minutes. But now the blocks are already filled by 70%. If the average confirmation time drops to 20 minutes, the blocks will be filled to 140%, that is, they start to accumulate in the queue.
In Bitcoin, there is a mechanism for regulating the complexity of evidence (proof-of-work) when the capacity of a network changes. This happens every 2016 blocks, which usually takes about two weeks. But we mine blocks every 20 minutes, so it takes four weeks.
Everything gets worse. Even after four weeks, 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” performance (70% coverage and periodic congestion). So, we will have to face a one and a half month period, when confirmations take two weeks to complete, and the cost of transactions is drastically increased. In addition, with such a large number of pending transactions, the memory of most of the nodes will be filled, probably most bitcoin transactions will not even be transferred, so sellers and wallets will not receive transaction notification within a few weeks.
If problems lead to a fall in Bitcoin prices, then mining will become even less profitable, and the vicious spiral will repeat.
It is not yet clear what the probability of the above scenario is (what I described as the worst scenario). It is possible that with a decrease in the mining remuneration, the cost of bitcoin will go up. And it is difficult to predict what percentage of hashing capacity can leave the network after the remuneration decreases. 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 is experiencing problems with congestion and queue. Any reduction in network capacity 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 shows their motivation and competence as a team. There is no reason to roll the dice and see if the worst case scenario comes to life.
Fortunately, some members of the community 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 problems.
What to do
- The first thing you need to immediately go to the blocks of 2 MB. This is the most realistic short-term solution that will gain us time. I think, or we will upgrade now (when everyone has enough time to prepare), or then we will have to upgrade on an emergency basis. There is a code to solve this problem . High quality code, written by former kernel developers, and already tested in production by many Bitcoin companies (including Coinbase). Upgrading Bitcoin Classic does not mean that we should stay on the Classic version forever, it's just the best way to eliminate the risks right now. In the future, we can use code from any group of developers.
- It is necessary to establish a communication channel 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 this group represents the greatest risk for their business. I will ask @cnLedger on twitter to help translate this post into Chinese and help distribute it (update: it's already translated ). We in the community need to build more connections with the Chinese miners.
- In the long term, you need to create a new group of development of the bitcoin protocol. A team that will be friendly to new developers will be prepared for a reasonable compromise 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 problem of scaling - the so-called “segregated Witness” system (SegWit).
Although this is a well-made technology, it seems to me risky to use this approach, given the situation described above. One of the main risks of using a new system is that it requires the implementation of a new code not only at the kernel level, but also with each purse provider that generates transactions. It is unlikely that this will be done in a short time and will allow you to avoid problems with scaling that threaten us. The number of lines of code that all industry participants need to write by several orders of magnitude exceeds the number of lines of code to change the block size from 1 MB to 2 MB. The kernel developers explained this at a conference, but they didn’t seem to change their mind about a short-term solution.
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, which I talked about. I think we can do it. In fact, we have to do it.
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 possible to implement the three steps described above. This is the best way out of a dangerous situation in which we find ourselves.
In the future, we need to form a new team to work on the Bitcoin protocol and help organize a “multi-party” system in order to avoid systematic risks for the kernel when only the team is working on a protocol. I hope this will be good news in the coming months.
Source: https://habr.com/ru/post/391265/
All Articles