POLL: What is the reason hard forks require broad consensus?

[Zangelbert Bingledack]

"Hard forks require broad consensus" is a common sentiment among the Core developers and the wider community. I want to get a sense of whether this is justified more by fairness/image considerations or more by perceptions that contentious hard forks are technically unworkable.

*For example, Adam Back said on reddit recently, "the network can not reach consensus with multiple competing incompatible consensus algorithms vying for control."

[1714149401]

1714149401

[1714149401]

1714149401

[1714149401]

1714149401

[1714149401]

1714149401

[1714149401]

1714149401

[1714149401]

1714149401

[Possum577]

You can't have a fork succeed if a majority of the volume of transactions will be able to be routed to the new system, to the fork.

But, idealistically you'd generate some sort of consensus among the community that the approach and timing of the fork is agreed up. Ideally isn't always reality though.

[Zangelbert Bingledack]

Food for thought... Why Meni Rosenfeld doesn't fear contentious hard forks:

http://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/

[Possum577]

Food for thought... Why Meni Rosenfeld doesn't fear contentious hard forks:

http://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/

It absolutely needs to happen. I think the debate was about does it need to be forced now or can it be arrived at organically, once it is really needed.

[Zangelbert Bingledack]

If I had to guess, I would say Core will up the limit early next year, probably modestly, in response to demand. If they stall too long, they risk losing some control over development.

[dothebeats]

If I had to guess, I would say Core will up the limit early next year, probably modestly, in response to demand. If they stall too long, they risk losing some control over development.

Speaking about control, how would that certain 'control' be lost in their hands when there are no central authorities that decide ultimately on who edits what?

[Lauda]

If I had to pick one of your options then it would be the following: "It would damage trust in Bitcoin (and the BTC price) to go against the wishes of any sizable portion of the community.". Anyone who suggests someone to take power in a system driven by a consensus algorithm for years is either a fool or evil actor (some people have suggested that the developers take power in order to decide on "controversial decisions"). Anyone with a tiny bit of common sense should not be thinking like this (thus the hard fork threshold should stay high in order to minimize damage).

Without broad consensus you don't have a upgrade of the network, you have a split resulting two partially damaged chains. At this point I'm pretty sure that a single controversial decision forced upon the users, i.e.  without broad consensus, could (at least partially) kill Bitcoin in its current (still fragile) state. At that point it would not be much different from the corrupt monetary system that we live in today. There are a few other coins that would be very appealing in that were to happen.

[Zangelbert Bingledack]

I'm not sure what "taking power" has to do with this. Are you talking about someone taking commit control of one of the implementations? (Wlad/Mike)

[saturn643]

Basically, contentious hard forks, and any sort of fork in general (hard or soft) requires consensus. The fork should only occur once a supermajority of the users switch to use the new rules. In most cases supermajority is defined as 95% of the last 1000 blocks, but its definition does vary. Without reaching supermajority, multiple competing blockchains can cause a loss of confidence, insecure network due to miners splitting to other chains, confirmation issues, and will in general be bad. This is why any code that involves any sort of fork, contentious or not, requires a supermajority before the node begins to enforce the new rules.

[Carlton Banks]

Bitcoin IS a consensus network.

Consensus is literally the fundament upon which the whole thing is based. If the nodes didn't agree on who owns which Bitcoin, then it's not even proper money, because there is no ledger.

[Lauda]

I'm not sure what "taking power" has to do with this. Are you talking about someone taking commit control of one of the implementations? (Wlad/Mike)

Well not exactly. Wlad has already commit control of Core so that's not right. What I was talking about is something that Mike seems to like, a 'benevolent dictator' (look up the terms Hearn and benevolent dictator in case you haven't read about it before) of Bitcoin. For example, Wladimir will not implement things that do not have a broad consensus and the developers have a right to veto. Taking power would mean to disregard this, and implement what you "feel" is right. Obviously this is bad on many levels.

[AndySt]

Consensus is the basis of life and activity of the bitcoin community. If some leaders will experience is the strength that nothing good will come out.

[Zangelbert Bingledack]

If the nodes didn't agree on who owns which Bitcoin, then it's not even proper money, because there is no ledger.

If there are two different consensuses among "the nodes," then there are effectively two separate sets of nodes now, so which set of nodes would you be referring to by saying "the nodes"?

[Zangelbert Bingledack]

I'm not sure what "taking power" has to do with this. Are you talking about someone taking commit control of one of the implementations? (Wlad/Mike)

Well not exactly. Wlad has already commit control of Core so that's not right. What I was talking about is something that Mike seems to like, a 'benevolent dictator' (look up the terms Hearn and benevolent dictator in case you haven't read about it before) of Bitcoin. For example, Wladimir will not implement things that do not have a broad consensus and the developers have a right to veto. Taking power would mean to disregard this, and implement what you "feel" is right. Obviously this is bad on many levels.

I've heard Mike mention "benevolent dictator" of his own implementation, but I thought that was in the context of having multiple implementation options for the Bitcoin community to choose from.

[brg444]

I'm not sure what "taking power" has to do with this. Are you talking about someone taking commit control of one of the implementations? (Wlad/Mike)

Well not exactly. Wlad has already commit control of Core so that's not right. What I was talking about is something that Mike seems to like, a 'benevolent dictator' (look up the terms Hearn and benevolent dictator in case you haven't read about it before) of Bitcoin. For example, Wladimir will not implement things that do not have a broad consensus and the developers have a right to veto. Taking power would mean to disregard this, and implement what you "feel" is right. Obviously this is bad on many levels.

I've heard Mike mention "benevolent dictator" of his own implementation, but I thought that was in the context of having multiple implementation options for the Bitcoin community to choose from.

There already are multiple implementations.

Moreover the whole thing is a facade and Mike knows all too well how the whole thing would've unfolded had people decided to move to XT. He clearly intended for all full nodes & miners to adopt the XT code base. So much for "multiple implementations"!.

[Zangelbert Bingledack]

Of course. Still with there being multiple choices it sounds like by "dictator" here we really mean "suggester."

[Lauda]

Of course. Still with there being multiple choices it sounds like by "dictator" here we really mean "suggester."

Not entirely right. With that he would be implementing code which he wanted to (who knows what could come out of this). In Core it is different, and consensus has to be achieved (a developer can veto a change). There are already multiple implementations so calling out for that is just a distraction from the actual plan.

[sx100]

........

 Without reaching supermajority, multiple competing blockchains can cause a loss of confidence, insecure network due to miners splitting to other chains, confirmation issues, and will in general be bad. This is why any code that involves any sort of fork, contentious or not, requires a supermajority before the node begins to enforce the new rules.

Is there any code change in a hard fork that prevents miners from continuing to mine the old chain, like changing the magic bytes, or changing the version number and adding code that blocks nodes running an earlier version number?

I remember some cut and paste alt devs didn't change the magic bytes when they changed an old coin's code into their new coin's code. There were sync problems, and people said the new coin was trying to connect to the old coin's network because they both had the same magic bytes.

[saturn643]

........

 Without reaching supermajority, multiple competing blockchains can cause a loss of confidence, insecure network due to miners splitting to other chains, confirmation issues, and will in general be bad. This is why any code that involves any sort of fork, contentious or not, requires a supermajority before the node begins to enforce the new rules.

Is there any code change in a hard fork that prevents miners from continuing to mine the old chain, like changing the magic bytes, or changing the version number and adding code that blocks nodes running an earlier version number?

Part of the validation is to check the version number. If the version number is not a certain number or higher then the block is considered invalid and it is rejected. Miners will never mine on an invalid block.

[knight22]

A fork doesn't need to reach a broad consensus. It only requires the consensus of those who fork. Plain and simple.