Deleted Account on Nostr: **Bitcoin Core v30 vs. Knots and BIP110: A Guide for Node Operators** **The ...

**Bitcoin Core v30 vs. Knots and BIP110: A Guide for Node Operators**

**The situation**

In October 2025, Bitcoin Core v30 raised the default OP_RETURN data limit from roughly 80 bytes to 100,000 bytes — effectively uncapped. Core's reasoning: the old filter wasn't working. Data embedders were routing around it using methods that were worse for the network, including fake public keys that permanently bloat the UTXO set and private deals with miners that bypass the public mempool entirely. Core's position is that node software should reflect what miners will actually mine, not attempt to referee which fee-paying transactions are legitimate.

Bitcoin Knots, maintained by Luke Dashjr, kept the strict filters and added more. Its supporters argue Bitcoin is money, not a decentralized hard drive, and that a filter works like a fence: imperfect, but it deters most abuse. Knots adoption grew from roughly 2% of the network to over 20% following the v30 controversy.

BIP110 is the escalation: a proposed soft fork that would enforce objective, size-based data limits at the consensus level — where miners cannot bypass them — with grandfathering of existing outputs and a built-in expiry mechanism.

**Critical fact: Core and Knots today enforce identical consensus rules.** Running either one does not and cannot split the chain. The difference is relay policy — what your node agrees to pass along.

**If you run Knots and BIP110 never activates:** Nothing breaks. You follow the same chain as everyone else. Your node simply refuses to relay data-heavy transactions, which is a protest vote and a bandwidth savings, not protection — those transactions still reach miners and still end up in blocks your node accepts.

**If you run Core v30 and BIP110 activates:** Because BIP110 tightens rules, a clean activation means your node follows the same chain and mostly doesn't notice. The risk is subtler: your node would accept a block containing newly-invalid data transactions, so if one gets mined, you'd briefly follow a chain the upgraded network rejects until it's reorged away. You'd be trusting others to enforce a rule you're not checking.

**Best case:** Overwhelming economic consensus forms one way or the other. Either BIP110 activates cleanly with broad miner and node support, ending the data debate at the consensus level, or the fee market resolves it naturally as data speculation fades — in both outcomes, one chain, no split, and the debate strengthens Bitcoin's demonstrated resistance to unilateral change.

**Worst case:** A contentious minority-hashrate activation. BIP110 nodes reject blocks that v30 nodes accept, producing a genuine chain split — the 2017 scenario. Exchanges list two assets, holders are confused, and Bitcoin's credibility as neutral money takes a hit. This is why serious proponents on both sides agree activation should only happen with overwhelming consensus.

**On illegal or inappropriate content:** This concern deserves a straight answer. Larger data allowances make it easier to embed objectionable material on-chain, and every full node stores the blockchain. Two mitigations exist: first, arbitrary data has been embeddable in Bitcoin since 2009 — the question is friction, not possibility. Second, OP_RETURN data is provably unspendable and prunable, meaning nodes can discard it after validation, unlike data hidden in fake public keys, which pollutes the UTXO set forever. Filter advocates respond that lowering friction still increases volume, and volume is what matters. Both points are true; the disagreement is about which harm is greater.

**On spam, bloat, fees, and who can afford a node:** Bitcoin's value as money for future generations depends on ordinary people being able to verify the chain themselves — on modest hardware, in America or Vietnam, without permission. Data bloat threatens that: it grows the chain, raises bandwidth costs, and crowds monetary transactions into higher fees. The filtering camp says this is exactly why deterrence matters, even imperfect deterrence. The Core camp says the block size limit — not relay policy — is what actually bounds chain growth, and that ineffective filters just push data into more damaging formats while handing miners a private fee market. Keeping Bitcoin pristine and keeping Bitcoin permissionless are both real values, and this debate exists because they genuinely tension against each other here.

**Practical takeaway:** You don't have to choose a tribe to choose a policy. Bitcoin Core exposes the same filtering options Knots ships by default — setting `datacarrier=0` and `permitbaremultisig=0` in bitcoin.conf gives you strict relay policy with Core's testing and release support. Whichever client you run, running a full node at all is the vote that counts. The network stays sound money only as long as its users can independently verify it — cheaply, globally, and without asking anyone.