Bitcoin Development Governance Proposal (BDGP-1)
If safety requires end users to follow mempool policy debates, the governance is broken.
Bitcoin’s development process has been broken for a long time and Bitcoin’s developers have failed the community.
99% of users should have never even heard of OP_RETURN, let alone know what it does — and the fact they do means Bitcoin’s developers have failed the community.
As a developer, you would only leak implementation details onto your user base if you are:
incompetent
attacking the network
both
The fact that non-technical users have had to learn about these details is a massive failure on the part of the developers.
Now you have users taking sides on a soft-fork debate purely based on their blind faith in influencers without understanding the technicalities.
When UX abstraction fails, politics invades the base layer:
Money that requires protocol literacy isn’t money yet. If non-technical holders must parse mempool policy, witness discounts, inscription hacks, or soft-fork signaling to judge existential risk, you’ve leaked governance from experts to the masses without giving them power — just anxiety.
Abstraction debt. Bitcoin’s developers are no longer shipping “safe defaults”. That created a vacuum where influencers do protocol comms, and users pick tribes by vibes.
Legitimacy hazard. The minute regulars think “the rules can shift under me”, your store-of-value narrative becomes contingent on whoever writes/merges code, not on time. That’s a reputational tax that compounds.
In the Bitcoin ecosystem (developers, miners/pools, exchanges/custodians, state/regulators), no actor with power is optimizing for “simple, sovereign Medium-of-Exchange for the masses”. They optimize for revenue, deniability, and policy compatibility.
All of this chaos and retail anxiety caused by developers will lead more people to ETFs/custody adoption and will lessen self-custody and MoE use.
If node policy changes keep enabling more and easier illegal payloads, pressure lands on runners/miners first.
Developers have to start treating Bitcoin’s users as stakeholders, not an audience they have contempt for.
If safety requires end users to follow mempool policy debates, the governance is broken.
Developers are paid to ship. Funders want visible movement; “no change” doesn’t justify grants. So maintenance drifts toward policy activism disguised as hygiene.
Why the dev process has been the preferred attack surface:
Cheaper than legislation: Defaults and “safety” framing do the enforcement work.
Plausible deniability: “We’re just improving performance”.
Captured developers is the most asymmetric attack vector - it hits sovereign users hardest, while leaving institutional wrappers unaffected.
Path dependence. Once UX, infra, and education conform to a default, reversing it is socially and economically expensive — so the ratchet holds.
The only way out of this is for the users to start working on a rough draft of constraints that should be imposed on the developers.
This is my rough draft proposal.
0) Premise — What Bitcoin Is, in Operational Terms
This is not about mission statements or ideology.
It defines the operational guarantees that make Bitcoin what it is.
Any proposed change that compromises these guarantees is presumptively invalid.
Essence (non-negotiable purpose)
Sovereign settlement rail that any unpermissioned peer can verify on commodity hardware.
Fixed monetary schedule (21M) with no dilution vectors via protocol semantics.
Censorship-resistant finality: adversaries with state power should face rising costs to block/alter settlement.
Self-custody viability at retail scale (not just institutions).
If devs can’t show the change preserves these under realistic adversaries, stop.
1) The Bitcoin Constitution for L1 changes (must be explicit)
A) Invariants (do not change unless proven existential failure without it)
Monetary schedule (21M), halving cadence, subsidy rules.
Proof-of-Work consensus (class: SHA-256 PoW; not swap-friendly).
UTXO model and validation semantics that define spendability.
Validation decentralization envelope: full node time, storage, bandwidth ceilings that a median user can meet (e.g., N min full nodes at <$X hardware, <Y GB chainstate, <Z Mbps).
Miner neutrality requirement: protocol must not require content adjudication by miners.
If a proposal touches these, it’s a hard red zone; needs overwhelming, objective proof of existential necessity and a robust rollback path.
B) Governable parameters (may change, but only inside strict envelopes)
To be discussed.
For these, require quantified tradeoffs vs node-cost envelope and a provable reduction in systemic attack surfaces.
2) Adversary model you must satisfy
State-level spammer with “infinite fees” to bloat UTXO, disk, and bandwidth. Public “Infinite-Fee Adversary” simulator: measure disk, CPU, bandwidth under spam/legal payload mix; publish before/after tables for any PR.
Legal contamination actor (malware/CSAM payload embedding for reputational or regulatory attack).
Monopoly relay/mining cartel steering templates/policy.
Cloud chokepoints de-peering/ToS-gating nodes.
Custodial paperization bloc (ETFs/exchanges) trying to externalize costs onto sovereign users.
Any change must reduce aggregate leverage of those adversaries or it’s net harmful.
3) Acceptance tests for any L1 change (must all pass)
Node-cost envelope: After rollout, a median user can still run/verify a node with commodity gear. Show before/after CPU, disk, bandwidth, RAM profiles under attack loads.
Sovereign survivability: Attack simulations show no growth in cheap spam vectors, legal contamination risk, or miner policy power.
Fee-market integrity: No subsidized paths that crowd out monetary transactions; no hidden resource asymmetries.
Roll-backability: Clear revert path (flags, versionbits, policy switches) if unforeseen externalities appear.
Economic neutrality: No change confers structural advantage to custodial wrappers over self-custody.
Clarity of blast radius: Strictly documented: consensus vs policy; what old nodes see; what breaks if minority rejects.
If devs can’t provide reproducible benchmarks/sims for each: do not merge.
4) Governance rubric (who decides, when to change)
Trigger conditions (when to even consider L1 change):
Safety: consensus bug, chain halt vectors, cryptographic break.
Liveness: demonstrated, persistent congestion that annihilates small sovereign users after policy-level mitigations.
Economics: provable erosion of fee market security in medium term (e.g., tail-risk undercut), with no policy fix.
Veto power explicitly recognized:
Economic majority nodes (merchants, exchanges) — measured via observables (template adoption, relay stats, miner signaling, economic clients).
Sovereign user quorum: a representative sample of independent nodes (not cloud-clustered) must be able to adopt without resource upgrades.
Miner veto is not enough; neither is “Core says so”. Need multi-constituency ACK (acknowledgment).
Process minimums:
Threat model doc, test harness, public attack sims; 90-day comment; 30-day red-team window; dual-implementation reference.
No semantic changes bundled with policy cleanups. One change per Bitcoin Improvement Proposal (BIP).
5) Abstraction debt (fix this first)
Default denial for high-risk payloads (large
OP_RETURN-like carriage).Clean separation in comms and code between policy (mempool/relay defaults) and consensus (rules).
Public risk dashboard: live metrics for UTXO growth, chainstate bloat, relay bandwidth, cloud/node centralization—so users see the costs the moment they move.
To be discussed further.
6) Policy Stance — What To Do Now
Bitcoin’s development policy should prioritize stability, clarity, and sovereign accessibility over expansion.
A) Pause on Expanding Base-Layer (Layer 1) Features
Implement a moratorium on new data-carrying functions at the base protocol level (Layer 1).
No additional mechanisms for embedding or transmitting arbitrary data should be added until thorough modeling shows that such changes reduce — not increase —:
Node operating costs, and
Legal or regulatory attack surface.
B) Tighten Policy Without Changing Consensus
Adjust policy defaults, not the underlying consensus rules.
Specifically:
Restrict
OP_RETURN, witness, and similar data paths to small, predictable sizes that minimize spam and legal ambiguity.Allow experimental or research-driven use cases only through explicit, opt-in flags — never through silent defaults.
C) Protect Sovereign Node Operators
Keep running a fully validating node affordable for individuals.
Maintain the hardware requirements (RAM, CPU, storage, bandwidth) well below consumer laptop thresholds.
Publish a target hardware budget with each release so users can verify that sovereignty remains practical.
D) Define and Document the Veto Process
Clearly outline how economic nodes — the exchanges, custodians, and users that process real economic activity — can refuse or delay changes that alter fundamental rules or economics.
Document how the network can continue operating safely even if a minority rejects such changes.
E) Communicate Through Invariants
Shift communication away from speculation (“we’ll figure it out later”) toward explicit guarantees:
Tell users which properties of Bitcoin cannot change,
Define under what circumstances — if any — those invariants could be reconsidered (only if existential).
7) Concrete red lines & green lines
Red lines (reject by default):
Anything that raises minimum node cost beyond consumer hardware.
Any path that subsidizes non-monetary data at scale (even if fees are paid) and invites legal contamination vectors that shift risk onto sovereigns.
Changes that rely on miner altruism or centralized policy clients to stay safe.
Bundling multiple semantics under one flag/day.
Ambiguous authorship of economic risk (who bears the cost if it goes wrong?).
Green lines (move forward):
Policy changes that reduce DoS/legal attack surface or lower node costs with zero impact on consensus.
P2P upgrades that improve relay privacy and reduce cloud choke points.
Tooling that improves key management, inheritance, Proof-of-Reserves — pulling adoption to self-custody without touching L1.
8) Don’t trust, verify
incentives > ideals; control > fairness; stability > truth
Incentives: Keep resource asymmetries from letting rich attackers buy externalities that poor users must carry.
Control: Do not hand miners/dev councils implicit vetoes via policy leverage; make veto multiparty and observable.
Stability: Favor policy-level clamps and node-cost ceilings over ideological purity wars.
Truth: Publish attack simulations, cost profiles, and invariants — so we measure, not sermonize.
9) What to do right now as a community
This is a very rough draft and I don’t have the time to work on this further.
If someone wants to work on it further/take the idea and write a better proposal, feel free to.
If we don’t fix the definition + invariants + process first, we’ll lurch from influencer-driven “consensus” to influencer-driven “civil war”. The way out is boring: quantified envelopes, explicit red/green lines, adversary-proofing, and no semantic surprises on L1. Everything else belongs on L2/L3 or in wallets — not inside the base layer that carries everyone’s life savings.
Bitcoin’s developers have failed us. Are we going to do something about it?
10) Big gaps in this proposal
Who enforces the “Constitution” without creating a new council of priests? A written Constitution creates an interpretive authority. If we don’t specify who interprets and how they’re selected/rotated, the “fix” becomes the new single point of failure (a soft standards committee that everyone treats as law).
Measurability — the envelopes need numbers and telemetry. “Median laptop” is vague. Attack-load costs must be benchmarked and published live.
Veto measurement — “economic majority” is Sybil-prone and easily gamed by custodians. “Economic majority nodes” measured by “template adoption, relay stats, economic clients” can be faked by custodians/exchanges and cloud clusters.
Rollbacks — soft vs hard, minority survival paths, and how to deploy flags without fragmenting relay. “Rollback path” is hand-wavy. In practice, rollbacks are socially hard.
Miner/relay incentives — policy tightening can backfire if miners profit from bloat lanes. Tightening policy while miners profit from bloat lanes (bigger witness discount, big OP_RETURN) outsources costs to node runners; the stance must address their P&L.
Funding incentives — Grants prefer “visible improvements”. Without maintenance KPIs, devs get paid to ship features. Grants/maintainers must be paid to not change things, or we’ll recreate the drift we dislike. E.g. 50% of grant pool to maintenance + sims + docs + telemetry; publish quarterly maintainer reliability metrics.
Legal-contamination language — If we anchor governance in “illegal payloads”, we pull courts and platform ToS into base-layer decisions.
Moratorium nuance — A hard moratorium can freeze safety work.
Core risk if shipped as-is: We can ossify into brittleness (no safety patches), or worse, centralize social power in the hands of whoever “interprets” the Constitution. If we don’t fix measurement, incentives, and process ownership, the document becomes another cudgel in influencer wars.
11) Implications if we don’t tighten governance now
Paperization accelerates: Retail anxiety → ETFs/custody. The Store-of-Value role survives, Medium-of-Exchange shrinks.
Policy capture migrates to app stores/clouds: If L1 won’t pick a lane, app stores and cloud Autonomous System Numbers (ASNs) will — under ToS, not code.
Legal chokepoints widen: The first major CSAM/malware scandal post-policy-loosening will outsource governance to courts — worst possible venue.