How do developers decide whether a Bitcoin upgrade will be a soft or hard fork?

[standardnepo]

I was reading about Bitcoin vaults today, and I saw that they would be introduced through a soft fork. I also know that BIP110 is a hard fork because I’ve read quite a bit about it on the forum.

This might be a silly question for developers, but I’m not a techie. I’m just trying to learn guys

[Livingleged]

I don’t know if I’m missing it but it’s like I’ve read it somewhere that BIP 110 is actually specified as soft folk, and not hard fork as you’ve said.

I think it’s just easy to differentiate the soft folk and the hard fork like this;

The soft folk introduce new rules that are stricter than the existing once. But older node will still be able to accept the block that are produced under the new rules.

While the hard fork introduced rules that are not compatible with the old rules, and older node will reject block that follow the new rules. Which causes split in the network if some node participants upgrade and some don’t

[Donneski]

Developers doesn't necessarily whether a Bitcoin upgrade will be a soft or hard fork?

First, what they do is look at what the proposed change actually requires at the consensus level. If the new rules can be expressed as a restriction of what is already valid, it can generally be deployed as a soft fork but if it requires making something previously invalid valid, that's a hard fork.
 
After that comes the most difficult part which is reviewing, testing and getting sufficient consensus for activation.

[NotFuzzyWarm]

know that BIP110 is a hard fork because I’ve read quite a bit about it on the forum.

St. Luke's contentious BIP-110 started as what he said was a *temporary* soft folk that DID violate the rules and broke several previously accepted tx's. That is just one reason it failed so badly.

Absolutely furious over kerfuffle that ensued, the megalomaniac St. Luke then did the ultimate hard fork - he flipped the bird to all his loyal followers who have BTC miners and created a completely new coin that he still insists is the "True Bitcoin" despite him changing the algorithm from using sha256 to Blake2B which requires completely different hardware. Hardware that has not been mass produced for around 4 years. But of course he still had a few of them and massively pre-mined his new coin for several days before announcing his new coin to the rest of his sheeple...

[pooya87]

If any change is to be applied the first thing developers will try to do is to apply it in a way that people don't have to upgrade their software after the change. That means it will be a "soft fork". The alternative that is "hard fork" would require everyone to upgrade their software to the latest version in order to be able to continue using bitcoin.

I also know that BIP110 is a hard fork because I’ve read quite a bit about it on the forum.

That is creating an altcoin out of bitcoin, it is different from "bitcoin upgrade" that you are asking for. But it is a hard-fork specially since they changed the hash algorithm and you would have to download a new software to be able to use it.

[athanred]

How do developers decide whether a Bitcoin upgrade will be a soft or hard fork?

It is simple. First, you try to do a no-fork. Which means making your changes within existing rules. An example of that is mining coins with OP_SIZE on DER signatures. It requires no consensus changes: https://bitcointalk.org/index.php?topic=5551080.0

Then, if for any reason, you don't know, how to make a no-fork, you can try making a soft-fork. It is difficult, it requires reaching consensus, and you can fail, if you won't convince enough people to support it. For example: https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

And later, if you try to activate your changes for a decade, and you fail, then it becomes a hard-fork, if you run out of patience, and you want to activate your changes anyway: https://ecash.com/

See? That's how some altcoins are made: a failed soft-fork can lead to an altcoin, if you don't reach consensus. Because there is not that much difference between extending a minority chain, or hard-forking, and having a completely new chain. In both cases, it is a fork, and it is in a minority, because if it would be in a majority, then it would have consensus, and would be activated as a soft-fork.

BIP 110 is actually specified as soft folk, and not hard fork as you’ve said

It is both: the original BIP-110 is a soft-fork, and nodes enforcing it are stuck at block height 961,639. I can still see such connections in my full node.

And then, on top of block 961,639, some people decided to apply a hard-fork, because producing a few blocks per week was too slow for them, even though it was perfectly blocking a lot of spam, even more than they wanted. Proof of Work is a great filter.

[ABCbits]

Aside from what other member said, technical, consensus and other trade-off also can be factor when deciding to push upgrade as soft or hard fork. For example, SegWit could be simpler if it's deployed as hard-fork.

The only point of controversy that (arguably) had some validity to it is that it would have been “cleaner,” code-wise, to deploy the upgrade as a hard fork instead of a soft fork, as this would leave less technical doubt in the protocol. Deploying SegWit as a hard fork would have had its own problems, however, which most developers and proponents of SegWit believed would have been much greater.

I was reading about Bitcoin vaults today, and I saw that they would be introduced through a soft fork.

Do you mean about BIP 443 or something else?I did quick search, but it leads to few different things, including custodial service which should be unrelated.

[athanred]

SegWit could be simpler if it's deployed as hard-fork.

Of course. Everything can be simpler, if done in a hard-fork way. However, if developers keep doing hard-forks, then they can introduce any changes, and nobody can stop them.

Do you mean about BIP 443 or something else?

It is unlikely to see next soft-forks, because now, BTC has a culture of no changes. Maybe BIP-54 will be activated, because it is already supported by some mining pools, and others may join soon. However, it will be probably deployed alone, because it is hard to reach consensus for other things, and it is too risky to delay BIP-54, only because people will disagree with something else.

Previously, hard-forks were considered risky, and that's why soft-forks were accepted, as a way of changing things. Now, even soft-forks are very political, so no-forks should be used instead. And then, new changes will be introduced, only when some developers will be annoyed enough, and will be tired of no-forks, otherwise we won't have that many soft-forks. Maybe BIP-54 is one of the last soft-forks we will see.

[standardnepo]

Do you mean about BIP 443 or something else?I did quick search, but it leads to few different things, including custodial service which should be unrelated.

I was reading about BIP345, but then I found out that it’s now closed so I’ll hopefully read about BIP443 soon. Tbh I don’t know the differences between them yet.

See? That's how some altcoins are made: a failed soft-fork can lead to an altcoin, if you don't reach consensus. Because there is not that much difference between extending a minority chain, or hard-forking, and having a completely new chain. In both cases, it is a fork, and it is in a minority, because if it would be in a majority, then it would have consensus, and would be activated as a soft-fork.

BIP 110 is actually specified as soft folk, and not hard fork as you’ve said

It is both: the original BIP-110 is a soft-fork, and nodes enforcing it are stuck at block height 961,639. I can still see such connections in my full node.

And then, on top of block 961,639, some people decided to apply a hard-fork, because producing a few blocks per week was too slow for them, even though it was perfectly blocking a lot of spam, even more than they wanted. Proof of Work is a great filter.

Oh so their intention was to apply a soft fork but then things didnt go the way they wanted, and they intentionally changed it to a hard fork, am i understanding this correctly? So when they failed to apply the soft fork and it became an altcoin they could actually give up on that altcoin and go back to bitcoin right? Hmm then it was these people’s decisions to stick with their altcoin.

Thank you very much for your detailed explanation athanred.

[Dearon Grif]

I don’t know if I’m missing it but it’s like I’ve read it somewhere that BIP 110 is actually specified as soft folk, and not hard fork as you’ve said.

I think it’s just easy to differentiate the soft folk and the hard fork like this;

The soft folk introduce new rules that are stricter than the existing once. But older node will still be able to accept the block that are produced under the new rules.

While the hard fork introduced rules that are not compatible with the old rules, and older node will reject block that follow the new rules. Which causes split in the network if some node participants upgrade and some don’t

Yes, that’s a good way to put it. A soft fork tightens the rules while staying compatible with older nodes, whereas a hard fork changes the rules in a way that can split the network if not everyone upgrades.

[athanred]

am i understanding this correctly?

Exactly. And, as most Bitcoin forks, they started calling their chain "Bitcoin", just like BCH community did in the past.

So, for the rest of the world, BTC is Bitcoin, with SHA-256 mining, and for them, their BIP-110 chain is what they call "Bitcoin", with Blake2b mining. As a user, you can use any chain you want, if you have pre-split coins, then they should be available in both chains, at the same UTXO.

they could actually give up on that altcoin and go back to bitcoin right?

You can always use more than one coin. Using altcoins is not a sin, whatever chain you consider to be "an altcoin". You can always use both, if you want to. It is up to the users, where they will go with their money.

In BIP-110 code, they explicitly disabled "failed" state, so they activated it, despite being in a hashrate minority. These protections are there, to avoid minority forks. But well, if they wanted to disable that code, live with a slow chain for three weeks, and then hard-fork to a different mining algorithm, then it is up to them. Their code, their choices. There is a separate topic in the altcoin land, if you want to know more: https://bitcointalk.org/index.php?topic=5595052.0

[Aljawaab]

Thank you all. ‎I've been reading through the posts to make sure I understand.
If am right, the core idea is: Old nodes still accept blocks under a soft fork but don't enforce the new rules. And under a hard fork they reject the new blocks and the network can split.
‎
What Iam still unsure about is this: Does a soft fork work smoothly only if most miners enforce the new rules?

[pooya87]

What Iam still unsure about is this: Does a soft fork work smoothly only if most miners enforce the new rules?

Essentially yes.
But soft forks work smoothly if they are implemented correctly which means using BIP-9 [1] mechanism to first have miners correctly signal their readiness for and acceptance of the fork and most importantly if one of the conditions is requiring a large percentage of the blocks in that period signaled readiness. Which is usually >90%.

To put simply in soft-forks we don't have 3 options. We only have 2:
1) Large majority of miners (eg. >95%) are supporting the soft fork, so it will go through smoothly
2) Less than "large majority" support it so the fork does NOT happen
3) [option that should not exist] Less than "large majority" support it but the fork goes through and splits the chain.

[1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

[Danish Ali]

I was reading about BIP345, but then I found out that it’s now closed so I’ll hopefully read about BIP443 soon. Tbh I don’t know the differences between them yet.

BIP-443 is the proposed replacement for BIP-345. BIP-345 was specifically created to build vaults. It included 2 new opcodes allowing for delayed withdrawals as well as a recovery path. The author decided to withdraw the proposal in favour of BIP-443 (OP_CHECKCONTRACTVERIFY), which can be used to create the same type of vaults, but can also be used to create other constrained spending paths, such as shared UTXOs used in projects like Ark and CoinPools.

Both of these proposals can be implemented using a soft fork. They do this by making the existing Tapscript OP_SUCCESSx opcodes more restrictive. Whilst old nodes will still accept blocks using these opcodes, upgraded nodes will enforce the new rules. This is how a soft fork maintains backwards compatibility. Any changes that would make the rules less restrictive, such as increasing the 21M limit, can’t be done using a soft fork and would require a hard fork.

Neither proposal is active, and BIP-443 is still a draft.

[BlackHatCoiner]

What Iam still unsure about is this: Does a soft fork work smoothly only if most miners enforce the new rules?

Right. If 51% of hashrate is still mining under the old rules, then you have a chain with new rules that most of the times brings the old ones back. But, if majority of hashrate is mining under new rules, and considers the old ones invalid, then the minority that mines under the old rules will be rejected by majority, and thus the chain with the most work will always be the one with the new rules. A client running the old rules will just normally see reorgs happening.