How do you evaluate a Bitcoin consensus change proposal?
Not whether you agree with the goal. Whether the proposal is safe to activate. Whether the code has been reviewed. Whether the activation threshold is high enough to avoid a chain split. Whether the timeline gave the community enough time to evaluate the risks.
There's no standard for answering those questions. The BIP process tells you how to format a proposal. It says nothing about whether the proposal meets a minimum bar for safety. No required review periods. No code audit standards. No activation threshold minimums. No chain split risk assessment.
I wrote a framework that fills that gap.
"Consensus Change Standards" is a 28-page paper with a 20-point Consensus Change Readiness Checklist. Binary scoring โ each criterion is met or not met. You can apply it to any consensus change proposal, past or future.
Here's what it looks like applied to BIP-110:
- 55% activation threshold (Taproot used 90%)
- Approximately 2 months from proposal to activation client (Taproot took nearly 4 years)
- Multiple developers reported bugs in the activation client
- No public evidence of testnet deployment
- Activation client listed alongside stable releases with no risk disclosure
Score: 4/20. Taproot scores 19-20/20. Those aren't opinions. Those are inputs and outputs.
The framework doesn't take a position on whether BIP-110's goals are right or wrong. It evaluates the process.
What else is in the paper:
- Historical analysis of how P2SH, SegWit, SegWit2x, and Taproot were proposed, reviewed, and activated โ with a comparison table of thresholds, timelines, and outcomes
- Tiered minimum review periods: 12 months for changes that add new validation rules, 24 months for changes that invalidate currently valid transactions
- Code audit standards: 3 independent developer reviews, comprehensive test suites, 3 months on testnet, fuzzing and adversarial testing
- Activation threshold standards: 90% minimum for miner-activated soft forks
- Sunset clause requirements for proposals described as temporary
- Legal analysis: negligence liability for developers who release defective activation clients, tortious interference from chain splits, fiduciary duty arguments from the Tulip Trading litigation, mining pool operator liability, and regulatory implications under IRS Revenue Ruling 2019-24
The legal section is what makes this paper different from anything else in the conversation. I'm a practicing litigator (California State Bar No. 343622, admitted to the U.S. District Court for the Central District of California), a solo Bitcoin miner, and a full node operator. If a reckless activation ever causes a chain split and someone loses funds, the standard of care exercised in the process will be the first thing that gets evaluated.
The framework is designed to outlast any single proposal or debate. You can use it to evaluate BIP-110. You can use it to evaluate the next thing that comes along. That's the point.
CC BY 4.0. Share it, build on it, translate it.
PDF: 
GitHub: 
Published by The Forum Press, a Fulks, Inc. company.
Asaf David Fulks, Esq. | California Attorney Bar #343622
Consensus Change Standards: Bitcoin Protocol Governance Guide
A 28-page framework with a 20-point checklist for evaluating Bitcoin consensus change proposals. BIP-110: 4/20. Taproot: 19-20/20. Free PDF.
GitHub
GitHub - asaffulks/consensus-change-standards: A legal and technical framework for evaluating Bitcoin consensus change proposals. 20-point checklist, activation threshold standards, chain split risk assessment, and tort liability analysis.
A legal and technical framework for evaluating Bitcoin consensus change proposals. 20-point checklist, activation threshold standards, chain split ...
