This question cropped up a few times lately with some people referring to RDTS as a hard fork attempt. Let me try to define how I perceive the terms to be used in Bitcoin development circles:
Soft ForkSoft Fork
A soft fork is a consensus change that is forward-compatible to existing node software. The rules restrict blocks to a subset of what was permitted per the prior rules. Miners need to upgrade to be compatible, otherwise they might include transactions or build blocks that are forbidden per the new rules. Non-mining unupgraded nodes can follow along even if they are unaware of the new consensus rules.
The network will generally coalesce on the new rules, if a soft fork is enforced by the majority of the hashrate. If there are any blocks that break the new rules, they are reorganized out by the hashrate majority disregarding them.
Hard ForkHard Fork
A hard fork is a consensus change that breaks forward-compatibility to existing node software. The new rules permit blocks that were rejected as invalid by existing node software. Only upgraded nodes can follow a hard fork, unupgraded nodes are either stuck at the fork height or follow a non-upgraded alternate chaintip.
Chain SplitChain Split
Whenever miners are working on two or more chaintips, we speak of a chain split. This happens organically when two miners find competing blocks at the same height. It also happens when not everyone adopts a hard fork or when a soft fork is supported by a minority of the hashrate and network.
Murch, please be more active on SN with this kind of excellent posts.
You have all my respect.
Thanks, the interest in my posts has been very encouraging.
One small note I'd add is that chain splits can occur due to factors orthogonal to the pure consensus algorithm itself, e.g. if the consensus algorithm was not fundamentally stabilizing to begin with. That is much less of a problem with pure proof-of-work networks like Bitcoin, although could still happen if network connectivity is reduced, e.g. during a prolonged and well-funded attack that also targets the relay networks.
From the perspective of a bip110 node, if a nonsignalling block is found after Aug 8, does the soft fork becomes a hard fork? Or is mandatory signalling a hard fork itself?
Mandatory signaling is basically a soft fork in itself. For mandatory signaling, RDTS nodes change the consensus rules for block headers to require one specific bit in the version to be set: previously, that bit was unrestricted, now only blocks with the bit set are permitted.
This soft fork causes a chainsplit when a non-signaling block is found, because Bitcoin miners continue extending the chain with the non-signaling block, while RDTS miners are building a separate chaintip from the block prior to the first non-signaling block.
There is no hard fork at play here.
It does not become a hard fork, because there is not a scenario where BIP110 nodes accept a block as valid that Core nodes reject as invalid.
If they change the proof of work mechanism to rescue a stalled chain, that would trigger a hard fork.
Right, but this is where the confusion is i think: a rule that says
all blocks must signalwhen coupled with very low hash rate enforcement effectively guarantees a chain split.If miners find a non bip110 compliant and then begin building new blocks on this, non soft fork nodes follow along happy as clams, but bip110 nodes behave very much like a hard fork.
I think I'm just being silly about definitions here, but there is something in this that I keep seeing in the discourse around bip110.
I think a lot of casual bitcoiners associate soft forks with compatibility -- as in we will all be on the same chain whether we enforce it or not. Maybe this is a very naive view, but I think it is widespread.
The reality here is that a soft fork is completely incompatible with any miner not enforcing it. Nodes follow the heaviest chain, unless they are bip110, in which case they proceed on whatever chain they think is valid.
This dynamic is causing all kinds of mayhem on X
Yes, a minority enforced soft fork can cause a permanent chain split.
If hypothetically the entire network had been using RDTS rules and then someone made a software change that removed the mandatory signaling, this would remove a restriction and would be a hard fork. Only nodes that upgraded to this new software would be able to follow along.
Oh wow. 8k sats in 3 minutes? Thanks generous reader.
I might begin commenting "doing Murch's work" on good posts
Someone has a hard chain for your soft splits.
Your post was potentially Kruw-cified?? 🪖
Wasn't me this time.
Hair trigger reply 😇😅
I will become even stronger: https://github.com/stackernews/stacker.news/issues/3149
soft - more 'strict' ruleset
hard - less 'strict' ruleset
is how i always remember them
nice concise post
But it's also a bit confusing since you can apply upgrades as soft forks. IIUC, this is done by adding new functionality to inert preexisting opcodes, and then restricting the validity of txs so that those opcodes only perform the new functions.
~AskSN
The key distinction most people miss: a soft fork is forward-compatible (old nodes still see the chain as valid), a hard fork isnt. Soft forks tighten the rules, hard forks expand them. Taproot was a soft fork because old nodes could still validate new blocks even though they couldnt see the new script types. That backward compatibility is why Bitcoin Core prefers soft forks for consensus changes.