Classic's "contentious hard fork" and "consensus"

[arnoudk]

An open letter has been released (I'll assume for the moment that it is genuine as it appears to be) that calls for "consensus" and calls on the community to avoid "contentious hard-forks".

It is a letter stating that the parties do not intend to run Bitcoin Classic in production, or mine blocks using Bitcoin Classic.

It's interesting to look at the arguments used.

The first is the call for "consensus". Unfortunately they have not defined what consensus means for them, so let me go by the dictionary.com definition:

noun, plural consensuses.
1. majority of opinion: The consensus of the group was that they should meet twice a month.
2. general agreement or concord; harmony.

If we take the first definition - a majority of opinion, then consensus would be reached when "50% + 1 vote" vote in favor of a change. The question is: is miner consensus what counts?
If it does, then a call for "consensus" is not needed, as bitcoin Classic has a rule in place that would only trigger the change if >75% of miners vote for the change. >75% is much, much more conservative than the dictionary definition of consensus.
Or is it the economic majority that counts? This is not as easy to measure - how do you define and measure the economic majority?
Or is it the "consensus" of the core devs that count? This argument has been made repeatedly on the basis that they are most well-versed in understanding the implications of such changes. There is clearly no "consensus" from the core developers that bitcoin should be hard forked. However, if the opinion of a handful of core developers is the "consensus" they are looking for, then bitcoin no longer serves its users as it is now run by a (group of) dictators. Whether they are benevolent dictators or not is irrelevant - if their opinion is the only one that matters, they could be bribed, blackmailed/extorted, or worse to use their power in unproductive ways.

Or should we take the second definition, of concord and harmony? This implies that consensus is 100% agreement on a subject. Let's examine what this actually means. If 1 person votes against a change, and everyone else votes for a change - there is obviously no harmony. Thus, a single person can boycot a change - for good or for bad. Using this definition of consensus results in gridlock. Absolutely nothing can be as uncontroversial that everyone without exception will agree. Nor should it be.

And so the redefinition of the word "consensus" begins. What is consensus? Is 75% of miners consensus? Is 95% of miners consensus? Remember that according to the dictionary, 50% + 1 vote amounts to consensus. So the word is being redefined. The definitions are arbitrary, and worse - in an open letter that claims that "consensus" is needed, the definition of consensus that they use is missing.

A call for "consensus" SOUNDS nice. Unfortunately, it only SOUNDS nice.


The letter also asks for the community to refrain from running a "contentious" hard fork. Again, without defining that "contentious" means to the authors, so let's use the dictionary.com definition again:

adjective
1. tending to argument or strife; quarrelsome: a contentious crew.
2. causing, involving, or characterized by argument or controversy: contentious issues.
3. Law. pertaining to causes between contending or opposing parties.

So anything that causes, or could cause, an argument is contentious. This means that, if everyone agrees on a change, but ONE single person is dead set against the change, there is an argument. Therefore, only when there is 100% agreement on a subject, is it considered not contentious.

This is an unworkable definition. Looking for a complete absence of arguments as a prerequisite for a change means that no change can ever happen.

A call for avoiding "contentious" hard forks SOUNDS nice. Unfortunately, it only SOUNDS nice.


Any proposed process, that allows a minority to block progress, is not democratic. It is not fair. And in my opinion, it has no place in a decentralized currency such as bitcoin.

I am in favor of a block size increase. I will use my voice to convince others, using reason and evidence as my tools. If I am alone in my conviction, or in the minority, then obviously bitcoin should not change to my wishes. Using the exact same logic - if the people against a block size increase are in the minority, THEY should not be able to block it.

It is not democratic if a minority can block progress that a majority wants.

The open letter is a document that contains no valid arguments, because it does not define the meaning of the words it uses. It obviously does not use the accepted dictionary definitions. There are no logical arguments, only arguments that prey on fear, on uncertainty and on doubt.

I welcome a revision of this letter that makes logical sense. Until then, it goes into my ever growing pile of FUD-articles related to the blocksize increase.

[BitcoinNewsMagazine]

Only thing that counts is blocks mined with Classic. Either the pools will start using Classic or not. Also consider that Blockstream has too much capital from investors to protect to allow an upstart client to interfere with their business plan, watch and see. I think Classic will follow the same trajectory as XT. I like Classic and am running a full node but I only expect that to encourage Core to move forward with SegWit as fast as possible and deploy in April per their roadmap. Sooner than later as I am surely tired of this drama.

[arnoudk]

Only thing that counts is blocks mined with Classic. Either the pools will start using Classic or not. Also consider that Blockstream has too much capital from investors to protect to allow an upstart client to interfere with their business plan, watch and see. I think Classic will follow the same trajectory as XT. I like Classic and am running a full node but I only expect that to encourage Core to move forward with SegWit as fast as possible and deploy in April per their roadmap. Sooner than later as I am surely tired of this drama.

Technically, it is true that miners will dictate what codebase is run. But miners do not operate in a vacuum, if they cannot sell coins for fiat to pay for their electricity (because there is no OTC market for their branch, and exchanges do not recognize their branch) then they will simply go bankrupt. Miners cannot choose to break bitcoin in some fundamental way, ie not process transactions and only keep the block bounty, because then the price of bitcoin will fall and they cannot pay their costs. Again, they would go bankrupt.

So miners cannot choose to force a choice that the community, and their clients, rejects.

Miners could, however, decline to enforce a change that the community demands. This is what we are seeing at the moment. The community cannot change the chain without miner backing. In this sense, it appears problematic that so few miners have veto power over upgrades. I, however, still believe that they will not destroy their investments in their mining farms, by crashing the system. A bitcoin replacement will be built if things go south, and you can be sure it will not include a sha256d proof of work algorithm.

[arnoudk]

Here's BitmainTech's response to the open letter (according to archive.is). The official page does not load. I am assuming the text on both sites is the same here.

Bitmain statement regarding "A Call for Consensus"
2016/02/11

BITMAIN/Antpool chose to abstain from signing the statement, “A Call for Consensus,” that was released yesterday by representatives of several bitcoin companies. The statement was produced as the result of extensive discussions between the Core team and key industry players over the past several weeks.

We applaud the Core team’s increased communication and willingness to find compromise, but we do not wish to bind ourselves to a document that does not contain concrete technical proposals. We look forward to reviewing Bitcoin Core’s updated roadmap and evaluating it on its technical merits, but we do not believe that this should be done to the exclusion of other development efforts.

Like those who signed the Call for Consensus document, we share the common goal of seeing bitcoin succeed. The bitcoin network has proven resilient in the face of many challenges over the years, and we do not believe that testing different implementations of the software poses a threat to the network. If support for a hard fork fails to reach majority consensus, then bitcoin’s built-in voting mechanism works as intended.

Bitcoin has always been free software, and in line with open source philosophy, we encourage and welcome all code proposals irrespective of the team proposing.

Bitmain Technologies, Ltd.
Beijing

[johnyj]

Only thing that counts is blocks mined with Classic. Either the pools will start using Classic or not. Also consider that Blockstream has too much capital from investors to protect to allow an upstart client to interfere with their business plan, watch and see. I think Classic will follow the same trajectory as XT. I like Classic and am running a full node but I only expect that to encourage Core to move forward with SegWit as fast as possible and deploy in April per their roadmap. Sooner than later as I am surely tired of this drama.

SegWit need at least 1-2 years to be reviewed and tested before there is major consensus on it. It might never get accepted because "it pretty much changes every piece of software that has ever written for bitcoin" (Pieter's own words). I guess no one except Satoshi has the right to do a reconstruction of bitcoin architecture

Today's bitcoin's architecture is mature and robust, it endured the test of time for 7 years and works well. There is no real customer demand to change to another architecture, only Blockstream's solution like Sidechains and Lightning network require SegWit. But I will analyze later, both Sidechains and Lightning network are just bells and whistles that do not bring any meaningful function but increased level of complexity and make bitcoin more fragile

[LiteCoinGuy]

Only thing that counts is blocks mined with Classic. Either the pools will start using Classic or not. Also consider that Blockstream has too much capital from investors to protect to allow an upstart client to interfere with their business plan, watch and see. I think Classic will follow the same trajectory as XT. I like Classic and am running a full node but I only expect that to encourage Core to move forward with SegWit as fast as possible and deploy in April per their roadmap. Sooner than later as I am surely tired of this drama.

SegWit need at least 1-2 years to be reviewed and tested before there is major consensus on it. It might never get accepted because "it pretty much changes every piece of software that has ever written for bitcoin" (Pieter's own words). I guess no one except Satoshi has the right to do a reconstruction of bitcoin architecture

SW will be ready&live within the next 2-3 months (roadmap). there is also no problem with consensus.

[johnyj]

Only thing that counts is blocks mined with Classic. Either the pools will start using Classic or not. Also consider that Blockstream has too much capital from investors to protect to allow an upstart client to interfere with their business plan, watch and see. I think Classic will follow the same trajectory as XT. I like Classic and am running a full node but I only expect that to encourage Core to move forward with SegWit as fast as possible and deploy in April per their roadmap. Sooner than later as I am surely tired of this drama.

SegWit need at least 1-2 years to be reviewed and tested before there is major consensus on it. It might never get accepted because "it pretty much changes every piece of software that has ever written for bitcoin" (Pieter's own words). I guess no one except Satoshi has the right to do a reconstruction of bitcoin architecture

SW will be ready&live within the next 2-3 months (roadmap). there is also no problem with consensus.

If that is true, then there is no slightest problem with consensus of Classic taking over. Looking from the numbers of 0.12 nodes, it seems the current blockstream support is 1/5 of the classic, I don't see how that 20% of support can be called "no problem with consensus"

[arnoudk]

I'd not say that there is no problem with consensus for SegWit. But this does depend on how you define consensus - and no one seems to bother sharing their definition and sticking with it.

I for one do not support a technology that is that new, with so much new code being required, to be rushed into production.

I think SegWit has advantages, and from what I understand it should be implemented as a hard fork. But it should only be implemented (hard fork, or soft fork) AFTER it has been extensively tested. You just cannot rush this.

So, SegWit is contentious because I don't think it should be rushed. There is a discussion. It's Contentious!!

And, SegWit has no consensus, because I don't agree it should be rushed and no 100% consensus is reached. NO Consensus!!

But what they are saying, is that they don't care about consensus and are happy to implement contentious changes because it is a soft fork. Which is saying: because you don't have to upgrade your NODE you don't have to be ASKED (except that you'll have to upgrade your wallet to send money to merchants using it, or to receive money by suppliers using it. And if you want to be able to use it, you actually have to upgrade your node too. And if you don't want to use it, and don't want to participate in SegWit transactions that are forced on you due to size constraints - you have this choice. So no consensus is needed) .

If SegWit gets released, I will not be using their transaction for a few months to a year at least. Let someone else lose money for using a rushed, undertested offering.

SegWit also has a theoretical risk why I believe it will not be used on a large scale before miners have given a big commitment and there is a super majority of hashing power supporting it. A SegWit transaction is basically an "ANYONE CAN SPEND" transaction. This is the trick that makes it valid to non upgraded nodes. However, if someone tries to spend that anyone can spend transaction, the miners must reject that transaction. There is some other data structure that defines for SegWit who can REALLY spend it. The problem is this: if someone sends a SegWit transaction (anyone can spend), and there is NOT enough miner support for SegWit (or it ever gets removed in the future, for whatever reason), then your money could be stolen if it is in a SegWit address.

This approach is not necessarily bad - P2SH was introduced in a similar way. But it can only happen when sufficient miners back it.