Bitcoin Forum

"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."

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.

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/ (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.

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?

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.

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)

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.

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.

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.

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.

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"?

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"!.

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.

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.

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.

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

By "implementing" I assume you mean suggesting. Or do I have this wrong and he is able to force downloads?

Consensus among who is the question?

Users of the network
or
Developers of protocol.

I think the way the OP has phrased the poll biases the results.  Consider the debated block size limit hard fork for example:  

The way the poll is written, it sounds that by "hard forking" (i.e., to a larger block size limit) that we would be changing something about Bitcoin's nature (we indeed would be changing a line of code in the reference client that has historically rarely been used but that is only a small part of Bitcoin's nature).

Remember, by not forking in the case of the block size limit we are changing something about Bitcoin's nature too.  We are completely changing the economic model that Bitcoin has operated under over its entire history (that the free-market equilibrium block size was smaller than the limit).

I would argue that forcing a new-economic paradigm for Bitcoin by not changing that line of rarely-used code is a vastly greater change to Bitcoin's nature.  I bet if the poll was written this way, the poll would show support for changes to code that preserve Bitcoin's nature.

In other words, it is changes to Bitcoin's nature that require broad consensus.

Implementation has nothing to do with the download of clients. Implementing code would mean pushing something controversial and releasing a new version. He has also once mentioned something about ignoring the longest valid chain. In other words he could implement something bad with partial support (bankers would love e.g. blacklisting). The others would have to follow or risk total chaos once the network splits. In Core you can't just implement/push whatever you want.

---

---

You need consensus because we're using a  consensus based algorithm.  (https://m.youtube.com/watch?v=sE7998qfjgk)