Core Principles
Bitcoin Roots exists to preserve Bitcoin as peer-to-peer electronic cash. Every line of code we change traces back to one of these principles. Nothing ships unless it strengthens them.
Bitcoin is peer-to-peer cash. The blockchain exists to settle value transfers between participants — nothing more. This principle rejects the “timechain” narrative that treats Bitcoin as a general-purpose database for storing arbitrary data.
In practice, this means restricting OP_RETURN to 80 bytes. That is sufficient for protocol-level tools like CoinJoin commitment tokens (CTX) and privacy-preserving construction patterns. It is too small for embedding artwork, smart contracts, or other non-monetary data.
Code reference: src/script/standard.h — MAX_OP_RETURN_RELAY reduced from 83 to 80 bytes. A relay policy enforcement that does not alter consensus rules.
The Bitcoin protocol belongs to the full-node community, not to mining pools. When protocol upgrades require 95% of hash rate to signal support, a single pool operator can block improvements indefinitely by refusing to participate. This gives industrial mining companies disproportionate control over the evolution of a decentralized protocol.
Bitcoin Roots replaces BIP-9 miner signaling with BIP-8 timelocked activation. Upgrades activate at a predetermined block height regardless of miner participation. The community decides through software adoption — not hash rate.
Code reference: src/versionbits.cpp, src/consensus/params.h, src/kernel/chainparams.cpp — BIP-8 timelock height implementation replacing BIP-9 veto mechanisms.
Scaling belongs on Layer 2. The base layer should be secure, minimal, and resistant to congestion. Bitcoin Roots does not implement Layer 2 optimizations — it does not claim to “optimize for Lightning.” Instead, this principle states that base-layer modifications should prioritize settlement security and censorship resistance, not payment throughput.
The Lightning Network and other Layer 2 protocols handle transaction volume. The base layer handles finality. Bitcoin Roots keeps them separate by design.
Note: This principle guides what Bitcoin Roots does not change. No Layer 2-specific code modifications exist in the current codebase.
Clean code, minimal dependencies, auditable by a single developer. Every modification to Bitcoin Core traces back to one of the four principles above. If a change cannot be justified by a principle, it does not ship.
The current diff is six files — 51 insertions, 2 deletions. A single developer can review the entire change set in an afternoon. No hidden behavior, no sponsored features, no corporate commitments.
Verify: git diff v25.0..roots/dev --stat — every line is visible, traceable, and attributable.
What We Oppose
Bitcoin Roots is defined as much by what it eliminates as what it adds.
BIP-9 requires 95% of mining hash rate to signal support for an upgrade within a 2-year window. This threshold gives any single mining pool operator the ability to indefinitely block protocol changes by refusing to signal. The SegWit 2x saga demonstrated this flaw clearly: pool operators signaled for changes the broader community explicitly rejected. Bitcoin Roots removes this veto entirely through BIP-8 timelocked activation.
Features that allow arbitrary data embedding transform the blockchain into a general-purpose database. This is not what Bitcoin is designed for. Bitcoin Roots restricts OP_RETURN to 80 bytes at the relay layer — sufficient for protocol-level commitment tokens and privacy tools, insufficient for embedding artwork, smart contracts, or other non-monetary payloads. The blockchain exists to settle value, not to store data.
Changes driven by corporate sponsor priorities rather than user needs. Bitcoin Roots follows a strict principle-first development model: if a modification does not strengthen one of the four core principles documented on this page, it does not ship. Period. No sponsored features, no roadmap commitments to external stakeholders, no corporate governance structures.