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 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 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 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.
So, in general, what should node runners be monitoring? Would one of the handful of major pools signaling immediately after the mandatory period begins be a sign to upgrade your node?
Assuming you are not operating a node that is transacting at a high volume, if you want to play it safe, just get any transactions you need to send confirmed before the mandatory signaling height and monitor the situation for at least a few hours when mandatory signaling begins. If you are running Bitcoin Core, your node will follow the heaviest valid chain and as long as you are neither mining nor transacting, a potential chain split would not negatively impact you.
In the first few hours you should be able to see whether BIP 110 suddenly got a huge increase in signaling. If the situation is unclear after a few hours, just lay back a little longer, I’m sure there will be plenty of discussion of what’s going on.
If you are running a lightning node, I would not recommend to depend on a BIP 110 node as your source for the blockchain. If the hashrate distribution stays somewhat similar to the current, BIP 110 nodes would likely fall behind and this could make you vulnerable to a channel being closed maliciously on you. If your node were to miss the unilateral close, it may fail to broadcast the justice transaction in time.
What if you are mining? I’m assuming the same conservative approach applies - pause the operation until all the dust settles and upgrade to a signaling version if the major pools begin signaling within the first few hours?
If you are mining, your choice is more complicated since you have an actual cost to mine, but your payout depends on the outcome. If you feel strongly about the outcome, you should mine in support for your preferred outcome. If you don’t feel strongly, you could either guess what you consider to emerge as the likely majority chain and mine that for higher revenue, or wait for a while until the dust settles to save your cost of mining.
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.