Source / pinned edition

Bitcoin consensus rules (editorial reconstruction from divergent witnesses)

Source of package btc.consensus

work
urn:btc:clir:consensus#BTC_CONSENSUS
kind
urn:btc:clir:consensus#custom_law

Reconstructed consensus with SegWit active

edition
urn:btc:clir:consensus#BTC_CONSENSUS_POST_SEGWIT
language
en
officiality
unofficial
materialisation
ABSTRACT_ONLY
life cycle
in_force: [object Object]

Fragments — 0

Reconstructed consensus immediately before SegWit activation

edition
urn:btc:clir:consensus#BTC_CONSENSUS_PRE_SEGWIT
language
en
officiality
unofficial
materialisation
ABSTRACT_ONLY
life cycle
in_force: [object Object]

Fragments — 0

Narrow editorial reconstruction keyed to Bitcoin Core v27.2 and the pinned witnesses

edition
urn:btc:clir:consensus#BTC_CONSENSUS_V27_2_RECONSTRUCTION
language
en
officiality
unofficial
materialisation
PINNED_EDITORIAL_RECONSTRUCTION
life cycle
—

Publications

URITypedocumentHashRetrieved
local:btc-consensus/editorial-reconstruction-v27.2text/plain; charset=utf-8sha256:7021c72338ca69042e5264d8f4faf118d97539cae003c98dd7ef7773cadb73af2026-08-31T00:00:00Z

Fragments — 9

article/1 · article

en · official · sha256:843056ed879c44308c7bccb6fc93e31bd1a000d3aafbbbe9815f28277f6ad52c

Статья 1. Status of the reconstruction There is no single authoritative textual specification of the subject. Core is the operative implementation witness; BIPs witness individual changes; the Wiki is a defective popular witness; and the whitepaper witnesses design intent only. This article records the reconstruction method, not an executable validity condition.
article/2 · article · referenced by: 4

en · official · sha256:3883dc74ef323acaaeb5d3cd5b7dd641c9e238dd86f2f9069f484d7e196fd7b1

Статья 2. Header validity in the narrow slice A candidate header must satisfy the proof-of-work threshold, its contextual difficulty rule, and a timestamp strictly greater than the median of the prior eleven timestamps. Difficulty changes only at the next height divisible by 2016; Core measures that period using 2015 elapsed intervals, an off-by-one quirk that is therefore retained as network behaviour. Outside that boundary the prior nBits is retained. The 256-bit compact-target arithmetic is checked by Core and supplied to this model as an empirical case result.

Referencing norms: HeaderIsValidInNarrowSlice, HeaderTimestampMustExceedMtp, KeepDifficultyOutsideBoundary, RetargetAt2016With2015Intervals

article/3 · article · referenced by: 4

en · official · sha256:b5f026747084a043e27b00374ddf822df3229c0363345f72673b70b156c908aa

Статья 3. UTXO inputs and value conservation Each input referenced by a candidate transaction must denote an unspent output in the case's closed UTXO snapshot. The sum of input satoshis must be at least the sum of output satoshis. Signature and Script validity are external cryptographic case facts, not rules reconstructed here. The two historic BIP30 duplicate-coinbase blocks are grandfathered exceptions.

Referencing norms: EveryInputComesFromLiveUtxo, InputsMustCoverOutputs, KnownBip30RepeatIsGrandfathered, TransactionIsValidInNarrowSlice

article/4 · article · referenced by: 9

en · official · sha256:63dd07fe4174d9a78ca33a0e46e009e892ee6e7e0191cd697dbabf10eb9eb9b1

Статья 4. Maturity and transaction lock times A coinbase output becomes spendable after 100 new blocks. A transaction is final when its absolute locktime is zero, has already passed the appropriate height or median-time-past endpoint, or every input sequence is final. BIP68 relative locks use block heights or 512-second median-time units; a disabled sequence has no relative lock.

Referencing norms: BlockRelativeLockMaturesAtRequiredHeight, CoinbaseInputMaturesAfterOneHundredNewBlocks, DisabledSequenceHasNoRelativeLock, FinalSequencesIgnoreUnsatisfiedLocktime, HeightLocktimeIsStrictlyEarlierThanBlock, TimeLocktimeUsesPreviousMtp, TimeRelativeLockMaturesAtRequiredMtp, TransactionIsValidInNarrowSlice, ZeroLocktimeIsFinal

article/5 · article · referenced by: 1

en · official · sha256:ecdd29141557af36faae9eb5df5e6ac59c1842085612f72cca48c1d5641e0954

Статья 5. Block subsidy and derived cap The subsidy starts at 50 BTC and halves at each 210000-height band, as in GetBlockSubsidy. The A3 height-band table is the executable presentation of that rule. The quantity below 21 million BTC is a consequence of the finite sum of those bands, not an independently asserted consensus limit.

Referencing norms: ApplyA3SubsidyAtHeaderHeight

article/6 · article · referenced by: 2

en · official · sha256:1d8621540ab20426c6e2425982ba4ba49f79808be711a1bd644f83d2e3bc0512

Статья 6. Selection between competing chains Among compared candidates, the chain with greater accumulated work is preferred. The whitepaper's expression "longest chain" is retained as a witness-of-intent proposition only: a case where a longer chain has less work must exhibit the disagreement rather than silently treating length as work.

Referencing norms: PreferGreaterCumulativeWork, WhitepaperLengthAndCoreWorkCanDiverge

article/7 · article · referenced by: 23

en · official · sha256:a8a79aa0fa7a4c8eb178161fb40be16aa8218ee425e31377e0b753fde15a4f5d

Статья 7. Version-bits deployment BIP9 evaluates deployment state at 2016-block period boundaries. On mainnet, 1916 signals in that period meet the 95 percent threshold; after the required locked-in period the deployment becomes active, while a timeout can fail it.

Referencing norms: BIP9ThresholdIsNinetyFivePercentOf2016, Bip9Activation, Bip9Activation/ActivateAfterLockedInPeriod, Bip9Activation/Active, Bip9Activation/Defined, Bip9Activation/FailAtTimeout, Bip9Activation/FailBeforeStart, Bip9Activation/Failed, Bip9Activation/LockInAtNinetyFivePercent, Bip9Activation/LockedIn, Bip9Activation/Start, Bip9Activation/Started, Bip9ActivationState, Bip9ActivationStep, Bip9ActivationTransition, attempted_transition, current_state, entered_state, initial_state, left_state, procedure_instance, state_before, valid_transition

article/8 · article · referenced by: 4

en · official · sha256:0f95840328653a0ce522271d2b9a40f440e5127ef6da6594dafd165da12eb080

Статья 8. SegWit as a subset revision The post-24 August 2017 SegWit edition accepts every block meeting the older rules only when its additional witness commitments also pass. Thus post-SegWit validity implies pre-SegWit validity, while some legacy-valid blocks are rejected by the later edition.

Referencing norms: PostSegwitRejectsMissingAdditionalWitnessRules, PostSegwitRequiresAdditionalWitnessRules, PostSegwitValidityImpliesPreSegwitValidity, PreSegwitAcceptsLegacyBlock

article/9 · article

en · official · sha256:81791872624bfb36c126036abc280b9d7afb4fab6693cfd9ad93c065198d9ace

Статья 9. Declared boundaries and measured limitation SHA-256, signature verification, Script execution, probabilistic finality, "six confirmations", and relay policy such as dust and RBF are outside this narrow consensus slice. The accepted DSL rejects an Integer at 2^256 - 1 (LDC-E1306), so a direct target-arithmetic model is not claimed; this is recorded as ERRATA-CANDIDATE BTC-256-I64. This article declares scope and limitation, not an executable validity condition.

The hash beside the text is the sha256 of its exact bytes. It is the check that the text shown matches the one pinned in the package: a divergence fails the oracle’s static analysis.