Источник / закреплённая редакция

Bitcoin consensus rules (editorial reconstruction from divergent witnesses)

Источник пакета btc.consensus

work
urn:btc:clir:consensus#BTC_CONSENSUS
вид
urn:btc:clir:consensus#custom_law

Reconstructed consensus with SegWit active

edition
urn:btc:clir:consensus#BTC_CONSENSUS_POST_SEGWIT
язык
en
официальность
unofficial
материализация
ABSTRACT_ONLY
жизненный цикл
in_force: [object Object]

Фрагменты — 0

Reconstructed consensus immediately before SegWit activation

edition
urn:btc:clir:consensus#BTC_CONSENSUS_PRE_SEGWIT
язык
en
официальность
unofficial
материализация
ABSTRACT_ONLY
жизненный цикл
in_force: [object Object]

Фрагменты — 0

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

edition
urn:btc:clir:consensus#BTC_CONSENSUS_V27_2_RECONSTRUCTION
язык
en
официальность
unofficial
материализация
PINNED_EDITORIAL_RECONSTRUCTION
жизненный цикл
—

Публикации

URIТипdocumentHashПолучено
local:btc-consensus/editorial-reconstruction-v27.2text/plain; charset=utf-8sha256:7021c72338ca69042e5264d8f4faf118d97539cae003c98dd7ef7773cadb73af2026-08-31T00:00:00Z

Фрагменты — 9

article/1 · article

en · official · sha256:843056ed879c44308c7bccb6fc93e31bd1a000d3aafbbbe9815f28277f6ad52cEN

Статья 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 · на него ссылаются: 4

en · official · sha256:3883dc74ef323acaaeb5d3cd5b7dd641c9e238dd86f2f9069f484d7e196fd7b1EN

Статья 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.

Ссылаются нормы: HeaderIsValidInNarrowSlice, HeaderTimestampMustExceedMtp, KeepDifficultyOutsideBoundary, RetargetAt2016With2015Intervals

article/3 · article · на него ссылаются: 4

en · official · sha256:b5f026747084a043e27b00374ddf822df3229c0363345f72673b70b156c908aaEN

Статья 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.

Ссылаются нормы: EveryInputComesFromLiveUtxo, InputsMustCoverOutputs, KnownBip30RepeatIsGrandfathered, TransactionIsValidInNarrowSlice

article/4 · article · на него ссылаются: 9

en · official · sha256:63dd07fe4174d9a78ca33a0e46e009e892ee6e7e0191cd697dbabf10eb9eb9b1EN

Статья 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.

Ссылаются нормы: BlockRelativeLockMaturesAtRequiredHeight, CoinbaseInputMaturesAfterOneHundredNewBlocks, DisabledSequenceHasNoRelativeLock, FinalSequencesIgnoreUnsatisfiedLocktime, HeightLocktimeIsStrictlyEarlierThanBlock, TimeLocktimeUsesPreviousMtp, TimeRelativeLockMaturesAtRequiredMtp, TransactionIsValidInNarrowSlice, ZeroLocktimeIsFinal

article/5 · article · на него ссылаются: 1

en · official · sha256:ecdd29141557af36faae9eb5df5e6ac59c1842085612f72cca48c1d5641e0954EN

Статья 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.

Ссылаются нормы: ApplyA3SubsidyAtHeaderHeight

article/6 · article · на него ссылаются: 2

en · official · sha256:1d8621540ab20426c6e2425982ba4ba49f79808be711a1bd644f83d2e3bc0512EN

Статья 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.

Ссылаются нормы: PreferGreaterCumulativeWork, WhitepaperLengthAndCoreWorkCanDiverge

article/7 · article · на него ссылаются: 23

en · official · sha256:a8a79aa0fa7a4c8eb178161fb40be16aa8218ee425e31377e0b753fde15a4f5dEN

Статья 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.

Ссылаются нормы: 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 · на него ссылаются: 4

en · official · sha256:0f95840328653a0ce522271d2b9a40f440e5127ef6da6594dafd165da12eb080EN

Статья 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.

Ссылаются нормы: PostSegwitRejectsMissingAdditionalWitnessRules, PostSegwitRequiresAdditionalWitnessRules, PostSegwitValidityImpliesPreSegwitValidity, PreSegwitAcceptsLegacyBlock

article/9 · article

en · official · sha256:81791872624bfb36c126036abc280b9d7afb4fab6693cfd9ad93c065198d9aceEN

Статья 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.

Хэш рядом с текстом — sha256 его точных байтов. Он и есть проверка того, что показанный текст совпадает с закреплённым в пакете: расхождение роняет статику оракула.