Bitcoin Core vs. Bitcoin Knots: two sides of decentralisation from a professional hacker’s perspective.
A quick intro: I’ve spent the last seven years finding and exploiting security issues in everything from software and networks to trains and power plants. I mention that because I’m looking at the Core vs Knots debate through a security practitioner’s lens, not a tribal one.
There’s a lot of noise around the Core vs. Knots debate right now, but much of it misses the real point. They’re not actually fighting over the same thing and this has meant that whilst people are focusing on the spam argument, we’re sleep walking into some big issues that should be discussed NOW.
Bitcoin Core developers are focused on block production decentralisation. Their concern is making sure every miner, whether a massive pool or a solo operator, has a fair chance to get transactions into a block. That’s why they push for neutrality. If a transaction is valid under Bitcoin’s rules and pays a fee, it should be relayed across the network.
Supporters of Bitcoin Knots are more focused on validation decentralisation. Their priority is keeping full nodes lightweight and affordable to run. They don’t want people priced out by spam or arbitrary data clogging up the blockchain. That’s why they push for stricter relay policies and filters. It makes life easier for ordinary users who want to run a node at home.
Here’s where a lot of confusion comes in.
* Consensus rules define what must be accepted in a block. These are universal.
* Policy rules define what your node chooses to relay or keep in its mempool. These are local choices only.
Filters can protect your own node, but they don’t stop miners from including those transactions if they want to. Neutral relay keeps miners on equal footing, but it also means node operators shoulder more of the load.
For me, one of the biggest threats to Bitcoin isn’t just spam or bloat. It’s the risk that private relay networks become “fast lanes” to miners. If that happens, the balance of power shifts. Transactions that reach miners through these networks will get priority, while transactions from ordinary node operators may lag behind.
This risk is even sharper if Knots-style filters slow down how quickly some nodes can relay transactions. A filtered mempool means your node might not broadcast as fast, giving private relay networks an even bigger head start in reaching miners. That could tilt block production toward those with privileged access, undermining fairness.
That creates a few dangers:
* It could tilt block production towards miners who are plugged into these relay highways, making the system less decentralised.
* It could make censorship easier. If relay networks decide not to carry certain transactions, those transactions may never reach miners in time to compete for block space.
* It could leave node runners with little to no influence over which transactions make it into blocks. At that point, running a node still helps you validate your own transactions, but it no longer contributes much to the fairness of the network.
And if that were to happen, Bitcoin risks becoming less like a neutral, permissionless monetary system and more like a controlled network where a handful of actors decide what gets confirmed. That would weaken the very property that makes Bitcoin valuable as money in the first place.
So this isn’t decentralisation versus centralisation. It’s about which form of decentralisation we prioritise today. Do we focus on keeping nodes light and accessible, or on keeping block propagation fair for miners?
If Bitcoin is going to grow into the world’s dominant money, it probably needs both.
So what’s the takeaway from this post?
For me, Bitcoin is a monetary network and I don’t want to see spam clogging up the blockchain. But I also want those running Knots to recognise that filtering alone won’t stop spam from ending up in blocks. That risk only grows if what gets into blocks is effectively decided by a handful of private relay networks and miners.
I don’t believe Core developers have been “compromised,” but I do worry about the attitude that unless you’ve contributed code, your opinion doesn’t count. That creates an echo chamber around Core, shuts out fresh ideas, and builds distrust among people looking in from the outside.
I think broader adoption of technologies like Stratum V2 is one of the best ways we can reduce the power of mining pools and relay networks. That’s where more of us should be putting our energy today.
And lastly, we need to drop the “us versus them” mentality. This needs open, hard conversations, not rushed decisions. I’ll be quietly running a slightly behind version of Core after the next release, because I’d rather take the time to understand the risks properly. What matters most is that as many people as possible understand the threats to Bitcoin, so we can work together on solutions, rather than a small group pushing updates when most people don’t even understand the why.