diff --git a/bip-consensus-change-readiness-standard.md b/bip-consensus-change-readiness-standard.md new file mode 100644 index 0000000000..716304b184 --- /dev/null +++ b/bip-consensus-change-readiness-standard.md @@ -0,0 +1,291 @@ +``` + BIP: ? + Title: Consensus Change Readiness Standard + Authors: Asaf Fulks + Status: Draft + Type: Informational + Assigned: ? + License: CC0-1.0 +``` + +## Abstract + +Bitcoin's BIP process provides a mechanism for *proposing* consensus changes +but sets no minimum standard a proposal must meet *before* the community +considers activation: no required review period, no code-audit bar, no +agreed-upon activation-threshold floor, and no required assessment of +chain-split risk. This BIP defines a voluntary readiness standard for +scheduled consensus-change proposals — submission requirements, risk-tiered +minimum review periods, code-audit requirements, activation-threshold floors, +a chain-split risk assessment, sunset requirements, and a 20-criterion +readiness checklist that classifies a proposal Green / Yellow / Orange / Red. + +The standard is advisory. It binds no one, mandates nothing, and confers no +authority to block a change; each node operator decides independently whether +to run any consensus change. A completed scorecard's only force is the +strength of the reasons it documents. + +## Motivation + +The BIP repository defines how a proposal is *written and tracked*. It does +not define when a proposal is *ready to activate*. In practice that gap has +been filled ad hoc, and the cost of filling it badly is a chain split. + +The historical record shows both the gap and its consequences: + +- **P2SH (2012)** set a ~55% coinbase-signal threshold; the signal fell short + on the first poll, the chain forked between enforcing and non-enforcing + miners, and the change carried only after it was re-cut to a hardcoded flag + day (April 1, 2012, block 173,805). +- **SegWit2x (2017)** advanced a hard fork through a separate client promoted + outside the reference client's review process, and was called off only days + before its planned activation. +- **BIP 110 (2025)** proposed a high-risk, restriction-class soft fork on a + 55% threshold and moved from first proposal to activation client in roughly + six weeks — an activation client whose own test suite was publicly reported + failing, and no chain-split risk assessment published before signaling + opened. + +None of these episodes went wrong for lack of a *proposal* mechanism. They exposed the +absence of a *readiness* mechanism. Adjacent open-protocol communities have +long had one in spirit — the IETF's "rough consensus and running code" +(RFC 7282), RFC 2026's maturity gates, the PEP → BIP → EIP lineage — the idea +that a change earns activation by clearing documented maturity bars. This BIP +makes that bar explicit for Bitcoin consensus changes, as guidance. + +A readiness standard also sits within the repository's documented remit: BIP 3 +counts processes, guidelines, best practices, and incident reports (e.g., +BIP 50) among the things BIPs describe, and it expressly leaves sentiment and +adoption tracking outside the repository's scope. This standard gives +proponents and reviewers a way to document readiness without asking the +repository — or its editors — to adjudicate it. + +## Specification + +The standard applies to **scheduled** consensus-change proposals. A genuine +emergency hard fork is evaluated against the emergency standards (Specification +§2, Category 4b) and is not scored on the checklist. + +### 1. Submission requirements + +A proposal submitted for review should include, at minimum: (A) a clear, +empirically supported **problem statement**; (B) a complete **technical +specification** sufficient for independent implementation; (C) a +**backward-compatibility analysis** identifying every transaction/script type +affected and quantifying users and value at risk; (D) a fully specified +**activation mechanism** (signaling method, threshold, window, timeout, defined +failure mode); (E) a **rollback procedure** — a self-executing sunset where the +proposal calls itself "temporary," and otherwise no affirmative obstruction of +future reversal; (F) a complete **reference implementation** with a test suite. + +### 2. Minimum review periods (risk-tiered) + +The tiers track risk to existing holdings and to network unity — whether a +change can invalidate currently valid transactions or split the chain — **not +the direction of the change**. Measured from publication of a complete spec and +reference implementation: + +| Category | Description | Minimum review | +|---|---|---| +| 1 — Low risk | Policy/relay changes that don't move the consensus boundary | Not a consensus change; out of scope | +| 2 — Moderate | Soft fork adding rules without invalidating any currently valid tx (e.g., SegWit, Taproot) | **12 months** | +| 3 — High | Soft fork that invalidates/restricts currently valid tx or risks fund loss (e.g., BIP 110) | **24 months** | +| 4 — Hard fork | Any change old nodes reject | **36 months** general; **4a scheduled: 5 years**; **4b emergency: compressed, threat-calibrated** | + +Hard forks additionally require explicit replay protection (or a published +rationale for its absence), demonstrated economic-node support, and a published +chain-split contingency plan. The need for replay protection is itself the +diagnostic of hard-fork status. + +### 3. Code-audit requirements + +Before activation signaling begins, the activation client must meet: +(A) **diverse independent review** — ≥ 3 reviewers whose organizational +affiliations differ from each other and from the authors, with prior +collaboration disclosed (the standard is diverse independent perspective, not +unachievable "pristine isolation"); (B) **test coverage** — unit, integration, +and regression tests, publicly reproducible; (C) **testnet deployment** — +≥ 3 months on signet/testnet, demonstrating activation, enforcement, and (if a +sunset is included) deactivation; (D) **fuzzing and adversarial testing**; +(E) **reviewer comprehension** — a named reviewer attests they understand the +consensus-critical change and can defend it, regardless of whether the code was +human- or AI-authored (the load-bearing requirement is comprehension, not +origin disclosure). + +### 4. Activation-threshold floors + +Thresholds are proposed as **minimum** standards, anchored to the chain-split +risk model (see Rationale): + +- **Miner-activated soft fork (MASF):** minimum **90%** of hashrate over a + signaling period of ≥ 2,016 blocks. 80–90% is risky (most of the safety + margin gone); below 80% is presumptively dangerous; below 60% is reckless and + should be rejected regardless of merit. +- **User-activated soft fork (UASF):** an extraordinary measure, appropriate + only where a proposal has completed full review, has demonstrated broad + economic-node support, sets an activation date ≥ 6 months out, and publishes a + chain-split contingency plan. + +### 5. Chain-split risk assessment + +Every proposal should publish a formal assessment addressing, at minimum: +(A) **hashrate-distribution analysis** (credible path to threshold?); +(B) **economic-node analysis** (exchange/processor/infrastructure support); +(C) **replay protection** (and, if a soft fork that can't split absent miner +defection, the documented rationale for its absence); (D) a **contingency plan** +for failed activation or a persistent minority chain (split-detection trigger, +chain/ticker naming, user communication, exchange/custodian coordination, +replay-risk disclosure, wind-down path). + +### 6. Sunset and reversibility + +A proposal that describes itself as "temporary" must include a **self-executing +sunset**: an exact block height or MTP at which the new rules cease, implemented +in the activation client, tested on testnet, and requiring no later fork or +software update to take effect. "Temporary but requires intervention to expire" +is permanent with a stated aspiration. + +### 7. Readiness checklist (the score) + +Mark each criterion **Met** or **Not met**. Two narrow classes are excluded +from numerator and denominator: **temporal** (19, 20 — cannot fairly apply to a +proposal that activated before any published standard existed) and +**structural** (11 applies only with a miner-signaling threshold; 12 only where +a UASF mechanism is used). No other N/A is permitted. + +**A. Proposal Quality** +1. Clear, empirically supported problem statement. +2. Complete technical specification; independently implementable. +3. Backward-compatibility analysis covering all affected transaction types, scripts, and use cases. +4. Fully specified activation mechanism (threshold, timeline, failure mode). +5. Rollback procedure; self-executing sunset if labeled "temporary." + +**B. Code Quality** +6. ≥ 3 expert reviewers from distinct organizations; prior collaboration disclosed. +7. Comprehensive unit, integration, and regression tests. +8. Test-network deployment (signet or testnet) ≥ 3 months; deactivation tested if sunset included. +9. Fuzzing and adversarial testing performed. +10. Named human reviewer attests comprehension of consensus-critical code. + +**C. Activation Safety** +11. Miner-signaling threshold (where used) ≥ 90%. +12. UASF (if used) has completed full review and broad economic-node support. +13. Chain-split risk assessment completed and published. +14. Replay protection, or documented rationale where soft fork cannot split absent defection. +15. Signaling only after the review floor elapses; enforcement ≥ 6 months after final client. + +**D. Community Process** +16. Minimum review period for risk category (12 / 24 months; hard-fork floors above). +17. Public discussion across diverse stakeholders. +18. Major exchanges and infrastructure providers consulted. +19. Chain-split contingency plan published by proposal author. +20. Structured evaluation against a published readiness standard, published or answered by proponents. + +**Classification**, by share of applicable criteria met: + +| Share met | Classification | +|---|---| +| 100% | **Green** — met all applicable minimums; ready for activation signaling | +| 75–99% | **Yellow** — gaps to address before activation | +| 50–74% | **Orange** — significant deficiencies; do not proceed to signaling | +| Below 50% | **Red** — not ready | + +Scorings should be published with their evidentiary basis and should cite the +edition/version evaluated against; the standard asks that evaluations be +legible and challengeable, not algorithmic. + +## Rationale + +**Why a 90% threshold floor.** Model post-activation hashrate as enforcing +(share *E*) and non-enforcing (1−*E*). The difference in cumulative work is the +same random walk Nakamoto used in §11 of the whitepaper; for *E* > ½ the +probability the non-enforcing chain ever leads by *k* blocks is +((1−*E*)/*E*)^*k*. These are first-passage probabilities over an unbounded +race, so they are conservative upper bounds for any finite activation window; +the finite-horizon double-spend analyses of Rosenfeld and Grunspan–Pérez-Marco +(see References), computed for the adversarial race, are a directional caution +the other way and do not narrow the gap that matters here. At the conventional +six-block finality depth (many services credit sooner, which only raises the +exposure): *E* = +0.55 → ≈ 0.30; *E* = 0.90 → ≈ 1.9×10⁻⁶; *E* = 0.95 → ≈ 2.1×10⁻⁸. Between 55% +and 95% the exposure does not taper — it collapses by five to seven orders of +magnitude. 90% is the lowest deployment threshold at which a modern soft fork has +activated without a split (Taproot), defended against a published model; 55% +(BIP 110, and P2SH in 2012) is not. BIP 91's 80% is not a counterexample: it +was a transient compulsory-signaling overlay coordinating BIP 141's 95% +deployment, not a rule-deployment threshold. The qualitative conclusion is +consistent with *BCAP* §3.5.2. + +**Why risk-tiered review periods.** The cost of getting a change wrong scales +with its blast radius. Additive soft forks (Cat 2) can be absorbed faster than +restriction-class soft forks (Cat 3) that invalidate existing transactions; +hard forks (Cat 4) carry split risk that organic node-upgrade cycles need years +to absorb (≈ 95% adoption takes ~2–3 years empirically; the 5-year scheduled +floor sits deliberately above that). + +**Why diverse review, not "unaffiliated."** Pristine reviewer isolation is +unachievable in a small developer community and weaponizable when claimed. +Diverse affiliation plus disclosure is achievable and legible. + +**Why comprehension, not origin disclosure.** Code origin (human vs. AI) is +undetectable on inspection; reviewer comprehension is testable in any review +forum. The accountable-named-reviewer requirement catches AI, copy-paste, and +not-understood code uniformly. + +**Why advisory (Informational).** The standard's authority is meant to come +from its usefulness, not from binding anyone. Each node operator decides +independently whether to run any change; the standard structures the decision, +it does not remove it. *(Under BIP 3's typology this is Informational — +"general guidelines or other information to the Bitcoin community." It is not +a Process BIP: BIP 3 describes Process BIPs as typically binding for the +corresponding process, and this standard binds no process.)* + +## Backward Compatibility + +None. This BIP specifies no change to consensus rules, network behavior, or any +on-chain artifact. It is a documentary standard for evaluating *other* +proposals. + +## Reference Implementation + +An interactive implementation of the Specification §7 checklist (live +Green/Yellow/Orange/Red scoring, with Taproot and BIP 110 preloaded as +reference scorings) is maintained in the project repository at + +(`docs/scorecard/index.html`, with a Markdown checklist `scorecard.md` and a +fillable `scorecard.pdf`), and served at +. + +## Reference Scorings + +Applying the Specification §7 checklist to the public record as of June 2026 +(per-criterion working and evidentiary basis: source paper §5.4, 5th ed. 2026): **Taproot** +17/17 applicable (Green); **BIP 110** 3/20 (Red); **SegWit2x** ≈5/17 +applicable (Red). A scoring grades the process by which a change was advanced, +as of the scoring date — not the outcome of its activation. A change can +activate without incident and still have been advanced outside every floor +above. + +## References + +- A. Fulks, *Consensus Change Standards: A Legal and Technical Framework for + Bitcoin Protocol Governance* (5th ed. 2026) — the full treatment; history, + legal analysis, and objections beyond this BIP's scope remain in the paper. + DOI 10.5281/zenodo.20651832. +- Ren Crypto Fish, Steve Lee & Lyn Alden, *Analyzing Bitcoin Consensus: Risks + in Protocol Upgrades* (Nov. 2024) [BCAP] — descriptive game theory this + standard complements. +- Meni Rosenfeld, *Analysis of Hashrate-Based Double Spending* (2014), + ; Cyril Grunspan & Ricardo Pérez-Marco, + "Double Spend Races," *Int'l J. Theoretical & Applied Finance* 21, no. 8 + (2018), — the double-spend race analyses + noted in the Rationale. +- BIP 3 (BIP process; replaces BIP 2), and the activations and mechanisms + referenced above: BIP 16 (P2SH), BIP 110, BIP 141 (SegWit), + BIP 340/341/342 (Taproot), BIP 9, BIP 8, BIP 148, BIP 91. +- RFC 7282 ("On Consensus and Humming in the IETF"), RFC 2026 (Internet + Standards Process). + +## Copyright + +This document is licensed under [CC0-1.0](https://creativecommons.org/publicdomain/zero/1.0/).