--- title: "Bitcoin Core vs Knots · Bitsaga Insights" description: "Here is what is actually being debated. There is no rule change to Bitcoin’s consensus.No coins are at risk. Your Bitcoin is not being redefined. This is a n..." url: "https://bitsaga.be/insights/bitcoin-core-vs-knots" language: "en" --- > Here is what is actually being debated. There is no rule change to Bitcoin’s consensus.No coins are at risk. Your Bitcoin is not being redefined. This is a n... [Insights](https://bitsaga.be/insights) · Technical # Bitcoin Core vs Knots By [Rob Segers](https://bitsaga.be/about) · January 8, 2026 ![Bitcoin Core vs Knots](https://bitsaga.be/images/insights/bitcoin-core-knots-3021052891.jpg) ##### Here is what is *actually* being debated. There is no rule change to Bitcoin’s consensus. No coins are at risk. Your Bitcoin is not being redefined. This is a **node policy debate**, not a protocol debate. ## Bitcoin Core Bitcoin Core is the reference implementation used by the majority of the network. Core’s policy is designed around: Maximum network reliability Fast block propagation Minimizing permanent chain damage (especially UTXO bloat) Policies that reflect what miners already accept Core does **not** try to morally judge transactions. It only tries to make spam **as cheap to clean up as possible**. --- ## Bitcoin Knots Bitcoin Knots is a fork of Core that adds **extra relay filters**. Knots tries to: Block certain transaction patterns Restrict OP_RETURN usage “Clean” the mempool from things it considers spam These filters **do not change Bitcoin’s rules**; they only affect: What your node relays What your node personally sees Miners and alternative relay networks simply bypass these filters. #### Why OP_RETURN Limits Don’t Stop Spam And Never Did **Filters don’t work. Economics do.** It doesn’t matter how many percent of nodes run Core: even at 100%, miners can trivially bypass policy filters via alternative relay networks (for example Nostr-style networks). That is *the* fundamental reason spam filters do not work in open networks: #### **They only affect *your* mempool, not the network.** Spam does **not** live only in OP_RETURN. OP_RETURN has existed since 2014 as a *designated trash bin*. Read the [original release notes](https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core), that was literally its purpose: ![OP_RETURN release notes](https://bitsaga.be/images/insights/Screenshot-2026-01-08-at-12.04.38.png) **OP_RETURN is damage containment** It is the *least harmful* place to dump arbitrary data: | Where spam goes | Why it matters | |---|---| | OP_RETURN | Prunable, minimal long-term harm | | Fake outputs | Bloats the UTXO set (non-prunable, permanent damage) | Bitcoin uses **economic incentives** to *nudge spam into OP_RETURN* instead of fake outputs because UTXO bloat is vastly more dangerous and harder to defend against. Filtering UTXOs would be **far more dangerous** than allowing OP_RETURN data. Opening OP_RETURN wasn’t “lowering standards”, it was **damage reduction**. ## **The fees are the filter** Spam is not stopped by byte limits. Especially witness data gets abused because it’s cheaper. Only **economic incentives** work in open networks. The OP_RETURN size limit never had a solid technical justification in the first place. --- ## Why the Change Was Made Spammers were already bypassing OP_RETURN limits by: stuffing witness scripts creating fake outputs → causing **UTXO bloat** Removing the limit: improves block propagation (fewer compact-block failures) aligns node policy with what miners already accept reduces UTXO damage increases network consistency Nobody *wants* spam; the goal is to make it **as harmless as possible**. Leaving the limit in place caused transactions to be chopped into multiple UTXOs → *more UTXO bloat*. Removing it **reduces permanent chain damage**. This is not “good vs bad.” It’s **flu vs cholera**, and OP_RETURN is the flu. --- ## Why Filters Are Actively Harmful Knots-style filters: Do **not** stop real spam *Do* block legitimate privacy transactions such as: BIP47 PayNym notifications Samourai Whirlpool TX0s (>42 bytes OP_RETURN) Filters always do this: they fail against attackers and punish real users. Raising the OP_RETURN limit instead of removing it would just repeat the same cycle: new legitimate use cases would exceed the new cap, and the drama would start again. 🗑 **If you have a trash bin, open it wide so the garbage stays off the street.** --- ## On Governance The online debate is poisoned by people who don’t know the technical or historical context. I actually understand how Core handled this. Bitcoin is not a democracy. It is a **technocracy**. People with deep technical knowledge make the calls and that is a *feature*, not a bug. You “vote” by running your own node but running Knots only affects your own mempool and changes nothing at the network level. If things ever truly go off the rails, **User Activated Soft Forks exists**. --- ## Final Note I run Core. But I’ll happily sell you a plug-and-play [Start9 node](https://shop.bitsaga.be/product/start-9-server-one-bitcoin-node/) so you can run Knots with one click. It’s your right. Just don’t confuse *local filters* with *network-level reality*.