Bitcoin Classic controversy is annoying, Gavin Andresen has something to say

Almost two years ago, I resigned as a Bitcoin Core maintainer, writing at the time:

I’m excited to focus more on protocol-level, cross-implementation issues, rather than on specific issues with the Bitcoin Core software.

I still think this way - focus on the protocol level, cross-execution issues, but I am a little upset by the recent series of expansion plans that have caused a lot of controversy (and hurt some people's feelings). I have participated in and supported these expansion plans, the first one was Bitcoin XT, the most recent one was Bitcoin Classic, and maybe in the future there will be Bitcoin Unlimited.

Madness! Chaos! Anarchy! ... I hear some people say this about me, am I crazy? Well. When I was a Bitcoin Core maintainer, I had three primary obligations:

1) Keep your system secure

2) Ensure that the network can process transactions reliably

3) Eliminate single points of failure

The above three points are still my top priorities, but now I try to take a higher-level view and focus on the entire Bitcoin ecosystem, not just the core software issues. So how should I start working?

The Bitcoin protocol is indeed well done and secure, but the "report bitcoin weaknesses mailing list" has been quiet for months. I am very pleased to see the adoption of multi-signature "p2sh". Although it is a bit stupid, I keep reminding people (you are smarter than me) to try to avoid mistakes during the protocol update and development process.

I still worry about the security of the Bitcoin network in the short term, which is why I’ve been so vocal about the block size issue, and part of the reason I support alternatives to Bitcoin Core. Whatever the solution, in the long run, I think it will all work out. Because smart engineers will find a way to fix the block size issue, whether it’s “extension blocks”, or using the Lightning Network, or sidechains, it doesn’t really matter. I like a nice, simple, clean solution, and most of the world’s greatest technologies are built on stubborn and horrible legacy foundations, and a lot of them work just fine.

Even without a short-term solution, Bitcoin technology will survive, but adoption and growth of the Bitcoin network may be delayed by a year or two.

So what about the short-term solution for scaling? This brings me to my third obligation: eliminating single points of failure. You can also think of it as “decentralize everything”, “diversity is good”, and “competition is good”.

One way to eliminate single points of failure is to try different solutions to a problem at the same time. This is a good strategy if you have enough resources, as it increases your chances of success and only fails if all solutions fail.

By analogy, it is best to have multiple teams for project development, which will reduce the chaos caused by the failure of one team.

Six years ago the Bitcoin ecosystem didn’t have the resources to support multiple development teams, but now it can.

As technology matures, specialization is natural. In the past, Ford Motor Company produced and assembled its own cars. Today, Ford has thousands of auto parts suppliers, and there is more than one supplier for each type of part, eliminating single points of failure.

I am doing my best to speed up this process for the Bitcoin network. I will contribute my advice and experience (and code reviews, code) to Bitcoin Classic, Bitcoin Unlimited, Bitcoin Core, and other upcoming open source projects. I hope that these solutions will succeed, and then make different divisions of labor for them according to the corresponding needs in the Bitcoin ecosystem. For example, miners may prefer Bitcoin Classic, and Bitcoin Unlimited may focus more on end users. Bitcoin Core will focus on longer-term improvements at the core protocol layer.

Or maybe they can decide their roles based on different cultures and decision-making procedures. You may think this sounds crazy, so I suggest you take a deeper look at the differences in attributes, decision-making, culture, etc. of various Linux distributions. Diversity is a good thing.

What if the various implementations can’t agree on what they are doing together? Linux has Linus, so who makes the final decision on Bitcoin’s consensus rules?

Satoshi Nakamoto gave the answer to this question in the conclusion of the white paper:

Nodes can leave the network at any time, and it is very easy to rejoin the network because they only need to supplement the proof-of-work chain received during their absence. Nodes vote through their CPU computing power to vote on their confirmation of valid blocks. They continue to extend the valid blockchain to express their confirmation, and refuse to extend the block after the invalid block to express their rejection. This framework contains all the rules and incentives required for a P2P electronic currency system.

Finally, I will say that I will continue to write more about incentives and the process of reaching consensus.

Original article: http://gavinandresen.ninja/classic-unlimited-xt-core
By GAVIN ANDRESEN
Translator: printemps
Editor: printemps
Source (translation): Babbitt Information (http://www.8btc.com/classic-unlimited-xt-core)