Источник / закреплённая редакция
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.2 | text/plain; charset=utf-8 | sha256:7021c72338ca69042e5264d8f4faf118d97539cae003c98dd7ef7773cadb73af | 2026-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 его точных байтов. Он и есть проверка того, что показанный текст совпадает с закреплённым в пакете: расхождение роняет статику оракула.