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
| URI | Type | documentHash | Retrieved |
|---|---|---|---|
| local:btc-consensus/editorial-reconstruction-v27.2 | text/plain; charset=utf-8 | sha256:7021c72338ca69042e5264d8f4faf118d97539cae003c98dd7ef7773cadb73af | 2026-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.