State of the debate: node policy, consensus, and who decides

⚠️ Time-sensitive — not re-verified since `asOf` (2026-07-22). The abstract policy/consensus distinction is durable; the governance snapshot hung on it is not. Core v30's OP_RETURN limits are treated as the dominant implementation's current default, the Core-vs-Knots implementation split as a present condition, and "the observed BIP-110 signaling outcome" as a settled reference point — though that outcome is recorded in op-return-and-arbitrary-data on owner testimony (2026-08-11), not a primary source. The sourcing note further down shows the pattern directly: two entries were added to this cluster on 2026-08-11 with no re-verification of the policy state, so asOf stayed at the last actual verification. Re-verify against a primary source before relying on current relay defaults, implementation shares, or BIP-110's disposition.

Beneath the data-embedding fight is Bitcoin's recurring constitutional question: which rules live where, and who legitimately changes them. The working distinction — policy is local (what my node relays), consensus is global (what blocks are valid; break it and you are on a different chain) — is agreed by all sides in the abstract and fought over in every application. Roughly half the room at the source event did not know the distinction, which is itself a finding: the community's most consequential debate rests on a concept most participants lack.

Live questions

• When the dominant implementation changes a default policy (Core v30's OP_RETURN limits), is that a neutral technical adjustment or de facto governance over the network? Defaults are sticky; most operators never change them.
• Is implementation plurality (Core vs. Knots vs. others) healthy redundancy or a coordination hazard? Both positions were argued: alternative implementations as pre-tested escape hatches vs. "Knots is Core with patches" — dependent on the upstream it protests.
• Can maintainers be captured — and does Bitcoin's "pull" model (anyone can fork the repo and run older rules) actually neutralize that, given real-world upgrade inertia?
• Do soft forks that restrict in-use transaction patterns respect or abuse the soft-fork mechanism? (data-restriction-soft-forks-are-true-soft-forks.)
• What is the legitimate role of node-count signaling (running Knots/v30 as a vote) when relay percolation means a filtering majority cannot bind miners? (minority-unfiltered-relay-defeats-filtering.)

Main positions (strongest forms)

1. Consensus-minimalist: Consensus rules are the only rules that matter and should change at most rarely and with overwhelming agreement; policy is local preference, and dressing policy fights up as existential is category error.
2. Policy-matters: Defaults shipped by the dominant implementation are network governance in practice; treating them as neutral hides power. Operators should actively choose implementations and settings, and implementation diversity should be built up before a crisis requires it.
3. Protocol-hardening: Some things are too important to leave at the policy layer — if data restriction (or any protection) matters, it belongs in consensus where it binds everyone, and the community should be willing to use soft forks for defense, not only for features.

Related corpus entries

relay-filters-cannot-stop-determined-data-embedding, minority-unfiltered-relay-defeats-filtering, op-return-filtering-is-technically-trivial, data-restriction-soft-forks-are-true-soft-forks, a-soft-fork-can-remove-arbitrary-data-from-bitcoin, filter-capability-invites-broader-censorship, one-honest-miner-preserves-censorship-resistance, small-block-position-was-vindicated, satoshi-made-correctable-engineering-errors, repository-control-confers-no-power-over-bitcoin, implementation-diversity-differs-from-rule-competition. Reference points: BIP-110 signaling mechanics; historical soft forks P2SH (BIP-16), SegWit (BIP-141), Taproot (BIP-341) as precedent cases.

A note on this cluster's sourcing. Seven of the entries above trace to the same recorded conversation, which is a real concentration risk — a cluster this contested should not rest on one evening. The two entries added 2026-08-11 are the first in this topic drawn from a book rather than a transcript (corpus/sources/the-blocksize-wars-book-notes.md, Bier). They only partially fix it: that source is a contemporaneous account of the 2015–16 scaling dispute and contains nothing on data embedding, OP_RETURN, relay filtering, Core/Knots or BIP-110, so it cannot second-source the four filtering-mechanics claims. op-return-filtering-is-technically-trivial and filter-capability-invites-broader-censorship remain single-sourced. The source also stops at February 2016, so UASF, the New York Agreement, Bitcoin Cash and SegWit2x — the episodes that actually resolved the question of who decides — are outside it.

Open questions a debate could resolve

• A crisp criterion for when a change belongs in policy vs. consensus that both camps would apply to past cases (v30 OP_RETURN, full-RBF, BIP-110) and get consistent answers.
• Whether "run a different implementation" is real governance for non-technical operators, or a liturgy — and what tooling would make it real.
• Who, concretely, each debater believes holds power over Bitcoin's rules today (maintainers, miners, economic nodes, exchanges), tested against the observed BIP-110 signaling outcome.
• Whether upgrade inertia (most nodes following defaults) is a bug to fix or the stabilizing feature that makes capture hard.