Consensus Parameter

A consensus parameter is any rule the protocol requires every full node to enforce identically. If two nodes disagree on a consensus parameter, they end up on different chains.

The major Bitcoin consensus parameters:

• Block weight limit. 4 million weight units. The post-SegWit replacement for the original 1 MB block size cap.
• Halving schedule. Subsidy halves every 210,000 blocks (~4 years), starting at 50 BTC, which caps the total at the 20,999,999.9769 BTC asymptote.
• Valid script opcodes and their semantics. Defined by the consensus implementation; what OP_CHECKLOCKTIMEVERIFY does, what OP_CHECKMULTISIG does, what's allowed in a SegWit witness, what's allowed in a Tapscript leaf.
• Difficulty retarget rule. Every 2,016 blocks, difficulty adjusts so the expected interval between blocks targets 10 minutes.
• Coinbase maturity. Newly-minted block rewards aren't spendable for 100 confirmations.
• Activation rules for soft forks. BIP 9 versionbits, the Speedy Trial variant that activated Taproot, BIP 8 - the rules for how new consensus parameters get activated are themselves a kind of meta-consensus parameter.

Changing a consensus parameter requires a coordinated soft fork (tightening rules, backwards-compatible) or a hard fork (loosening rules, splits the chain if not unanimous). The bar for either is high. Bitcoin's parameter set has been deliberately stable: the soft forks most people can name arrived a few years apart, P2SH (2012), CLTV (2015), CSV (2016), SegWit (2017) and Taproot (2021), and the full list of consensus changes in Bitcoin Core's doc/bips.md adds only a handful more.

That stability is itself a feature. Money's value comes partly from confidence that the rules won't change. A consensus parameter that's been unchanged for a decade tells holders something an arbitrary-policy chain can't.