Who decides if a code change is a "hard" fork or a "soft" fork?

[rekumit]

Who decides if a code change is a "hard" fork or a "soft" fork?

Does Bitcoin have an issue of trust if ultimately it’s the responsibility of the development team, a few individuals, to approve and update the source code? I’m sure they’re good trustworthy people. But what about their successors?

[ranochigo]

Who decides if a code change is a "hard" fork or a "soft" fork?

It depends on the kind of changes implemented. If the change impacts the older client such that they can no longer continue to be on the same chain as the newer client, then it is a hard fork. This can be something like a change in block size limit, sigops, TXID structure, anything that results in the older clients being unable to recognize something that gets implemented in the newer client.

Does Bitcoin have an issue of trust if ultimately it’s the responsibility of the development team, a few individuals, to approve and update the source code? I’m sure they’re good trustworthy people. But what about their successors?

The nature of the open source codes gives the user a chance to review and decide which kind of changes they want to include or omit. Just because they've merged any changes, it doesn't mean that you have to follow them as well.

[NotATether]

The dev team cannot simply decide to make a soft fork, this is the entire reason why BIPs were invented in the first place to give the wider bitcoin community an opportunity to criticize the proposals via the mailing list or Github.

And even then the BIPs are not immediately merged, a special activation window is created by assigning a bit in the block flags for miners to signal if they want to approve this change (which will not take effect unless a predefined majority of miners signal).

Whereas a hard fork can be done by pretty much anyone at the cost of isolating them from the main network. At this point, it would be illogical to think that the dev team would collectively make a hard fork without other devs coming in and maintaining the old one.

[BlackHatCoiner]

Who decides if a code change is a "hard" fork or a "soft" fork?

As said, if the change splits the chain in two separate chains, then it's a hard fork. There won't be the so-called “harmony”. An example of hard fork is Ethereum Classic. The developers hard forked Ethereum, because they believed that it wouldn't be appropriate to keep a $50M hacker's transaction. They simply removed it and let the people decide if they want to extend the chain with the malicious transaction or not. Hence, two Ethereums.

The difference with a soft fork is that only one block chain will remain valid. The users have to adopt the changes. Examples of soft fork in Bitcoin are SegWit and Taproot.

[ABCbits]

Who decides if a code change is a "hard" fork or a "soft" fork?

It's not "Who", but "What". Basically if there's backward compatibility, usually it's classified as "soft" work. Usually user and node operator don't need to upgrade or change their software.

For example, SegWit could be implemented as "hard" fork where there's less complexity. However SegWit is implemented as "soft" fork, where there's more complexity due to backward compatibility.

Does Bitcoin have an issue of trust if ultimately it’s the responsibility of the development team, a few individuals, to approve and update the source code? I’m sure they’re good trustworthy people. But what about their successors?

The nature of the open source codes gives the user a chance to review and decide which kind of changes they want to include or omit. Just because they've merged any changes, it doesn't mean that you have to follow them as well.

Additionally, there are multiple software to run Bitcoin full node, so you're not forced to use specific software. However, some people find Bitcoin Core having big influence as a concern.

[zbig001]

"A hard fork removes or relaxes consensus rules."
Your old client sees these blocks as invalid, I bet.

"A soft fork introduces a new rule or makes the rules more restrictive."
Your old client cannot validate all block content, but recognizes the block as valid.

[rekumit]

Thanks for the answers everyone.

So if I'm understanding correctly, the distinction between a "soft" and "hard" fork isn't made by a human or humans. It's determined by the technical implementation. How does that work? i.e. How does the software determine if a change to the protocol is backwards compatible?

[TryNinja]

How does that work? i.e. How does the software determine if a change to the protocol is backwards compatible?

If you change the block size limit to 10 MB and try to mine one with this size, the other nodes will see your block as invalid because they have a rule that says so. Meanwhile, your "10 MB" nodes will see the block as valid and will propagate/keep them between themselves. Congrats, you just forked the blockchain through your own hard fork.

If your change still produces valid blocks (that follows the rules) in the eyes of everyone else (the older versions), then it's a soft fork.

[rekumit]

Thanks, this is helping me understand. So the only way to "soft fork" is to change the validation function and have the majority of miners pick it up? The result being that the most prevalent validation function used by the miners being the most likely to produce the longest chain?

[pooya87]

"A hard fork removes or relaxes consensus rules."
Your old client sees these blocks as invalid, I bet.

"A soft fork introduces a new rule or makes the rules more restrictive."
Your old client cannot validate all block content, but recognizes the block as valid.

This is wrong. A fork can do either whether it is considered soft or hard. The distinctive factor that makes one soft fork and the other hard fork is backward compatibility. In other words if all the nodes have to upgrade to continue syncing then it is a hard fork, otherwise if they can still validate without needing to upgrade then it is a soft fork.

Thanks, this is helping me understand. So the only way to "soft fork" is to change the validation function and have the majority of miners pick it up? The result being that the most prevalent validation function used by the miners being the most likely to produce the longest chain?

Whenever something is changed in consensus rules through a soft/hard fork, in a decentralized system like bitcoin the consensus has to be reached before that change can be accepted. That means having the majority accept that change by "casting their votes" which is done by miners changing their block versions to show their "vote".

[rekumit]

Whenever something is changed in consensus rules through a soft/hard fork, in a decentralized system like bitcoin the consensus has to be reached before that change can be accepted. That means having the majority accept that change by "casting their votes" which is done by miners changing their block versions to show their "vote".

I think I understand - so a soft forked version of the protocol will only be accepted if a threshold of miners broadcast the version with their block.

[pooya87]

I think I understand - so a soft forked version of the protocol will only be accepted if a threshold of miners broadcast the version with their block.

Essentially that is what it all comes down to, 1 CPU 1 Vote. But it is slightly more complicated than that. You see bitcoin is not just the miners, it is all the people that are using it. More specifically the full nodes that are securing the network and the economy that is built on top of it.
For example if all miners decided to do a malicious fork today it won't be accepted by anyone and they would be mining something worthless and their chain won't grow because all nodes (except the ones that they run) will reject their chain.

[BlackHatCoiner]

For example if all miners decided to do a malicious fork today it won't be accepted by anyone and they would be mining something worthless and their chain won't grow because all nodes (except the ones that they run) will reject their chain.

Wouldn't that be a special case? If all miners decided to do that, then there wouldn't be any miners left for the “correct” chain. Even if the Bitcoin nodes left, that simply relay information, reject the malicious change, how would the old chain be extended? Wouldn't they be forced to either accept the new miners' chain or hard fork the already existent?

I think I understand - so a soft forked version of the protocol will only be accepted if a threshold of miners broadcast the version with their block.

Yes, it seems that in Bitcoin, the miners can actually vote for a network rule change, in contract with what this forum says.  

It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.

[Pmalek]

Bitcoin miners "vote" on the ordering of transactions, but that's all they do.

This isn't really the best place to talk about this, so hopefully OP wont mind that I am kind of hijacking his thread to ask this question. But since you mentioned the ordering of transactions, something crossed my mind.

I was reading about PoH yesterday. I am not sure whether to call it a new type of consensus mechanism or a type of hybrid PoS model. Anyway, the idea is that each transaction is ordered based on a timestamp by a decentralized network-wide clock within milliseconds. Thus, miners don't have to vote on the ordering of those transactions and the network is lightning fast. I am not going to mention which alt uses such a model, but I did find it an interesting approach. Would like to hear what those with more technical expertise think about it.   

[pooya87]

For example if all miners decided to do a malicious fork today it won't be accepted by anyone and they would be mining something worthless and their chain won't grow because all nodes (except the ones that they run) will reject their chain.

Wouldn't that be a special case? If all miners decided to do that, then there wouldn't be any miners left for the “correct” chain. Even if the Bitcoin nodes left, that simply relay information, reject the malicious change, how would the old chain be extended? Wouldn't they be forced to either accept the new miners' chain or hard fork the already existent?

That is an extreme example for an extreme case so obviously it would also require extreme actions to mitigate it, something such as an emergency patch to do something about the difficulty manually or even in a more extreme case to change the mining algorithm.
In reality malicious changes only have a minority support (eg. bitcoin unlimited or bitcoin cash) and they are simply rejected by the super majority. Worst case scenario is a slower main chain until the difficulty adjustment.

[ranochigo]

Yes, it seems that in Bitcoin, the miners can actually vote for a network rule change, in contract with what this forum says.  

It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.

Technically, it is not wrong. Miners can signal their support for various protocol changes to ensure a smooth transition for any soft forks or hard forks. It is always better to have support for all of the parties involved in the network before implementing any significant changes. But it doesn't necessarily mean that we need their consent in order to change any network rules. UASF was something that was proposed after the miners were not willing to signal support for Segwit and it would've resulted in a forced activation of segwit without the participation of majority of the miners.

Most of the soft forks were MASF, up to this day. But it doesn't mean that we strictly require the miner's consent to implement any network changes, though that would potentially introduce certain side effects for non-upgraded nodes, etc.