Changing Bitcoin's consensus rules without splitting the network requires coordination among participants who share no organization. Signalling mechanisms are how that coordination is measured.
Soft forks tighten rather than expand
A soft fork makes previously valid transactions invalid, narrowing what the rules permit. Blocks following the new rules remain valid under the old ones.
This backward compatibility means nodes that have not upgraded continue to accept the chain, seeing nothing unusual.
A hard fork does the opposite, permitting something previously invalid, which means old nodes reject the new blocks and the chain divides.
Compatibility depends on enforcement
Old nodes accept new-rule blocks, but they also accept blocks violating the new rules, since they do not know the restriction exists.
If a substantial share of mining power ignores the new rule, blocks breaking it will be produced and old nodes will follow them.
Upgraded nodes reject those blocks, so the network splits along the line of who is enforcing what. Broad enforcement is therefore a precondition rather than a preference.
Signalling measures readiness
Miners indicate readiness by setting a designated bit in the blocks they produce, and activation logic counts how many blocks in a period carry it.
Crossing a defined threshold within the period locks in the change, after which enforcement begins at a specified point.
Signalling indicates intent rather than guaranteeing behavior, since a miner can signal and then produce a non-compliant block, though doing so would risk having it orphaned.
Miners are not the only participants
Economic nodes, particularly exchanges and custodians, decide which chain they accept, and their choices determine which chain has value.
Approaches that let nodes begin enforcing a rule at a set time regardless of miner signalling shift the initiative toward node operators.
These approaches carry a higher risk of a split if enforcement begins without sufficient mining support, which is why they are debated rather than used routinely.
Why activation debates take years
There is no authority that can decide, so agreement must be assembled across developers, miners, businesses and users with differing priorities.
The cost of getting it wrong is a chain split, which is far more damaging than a delayed feature, so the process is deliberately conservative.
Proposals accordingly spend long periods in review and testing before activation is attempted, and the extended timeline is a property of the coordination problem rather than a failure of it.
The same conservatism explains why most accepted changes have been narrow. A restriction affecting one specific script type is far easier to assemble agreement around than a broad structural revision.