Bitcoin is a money protocol. Being a protocol with no central authority, it is subject to a complex balance of powers (read more here) that govern the set of rules it operates under. Due to this, different users of the network have different roles they play in ensuring the network stays decentralized and secure. That being said, there have historically been changes to Bitcoin. In order for these changes to occur, general consensus amongst the users was required. As with any other communal decision, this required debate. Bitcoin is currently undergoing another such debate. This has become a point of contention amongst node runners on which Bitcoin node software implementation one should run: Bitcoin Core or Bitcoin Knots.
While maintaining a nuanced stance, I have continued to seek out understanding of this current debate despite the vast amount of noise and division that exists on online forums. As a citizen of the world, I feel there is a responsibility to understand this subject correctly so that I may make the best decision I can on which node version and implementation I will run.
I recently had the distinguished pleasure of having a conversation with Adam Back about the subject. Given his history in Bitcoin, he provided me with a perspective wrapped in historical context. I was impressed with his balanced mind, and the thoughts he shared. After having subsequent conversations with other voices in the community, a clearer picture has formed. Such as any other kind of conversation regarding governance, history is vitally important. It is important to understand how we got here, so that we can best decide where to go. The intent of this article is to provide that historical context as it relates to the current debate, and a balanced educational perspective of the subject as a whole.
Block Size Wars
Before discussing the current subject of debate, it is best we review the block size wars. The Bitcoin block size wars (2015–2017) was a pivotal conflict over how Bitcoin should scale as transaction demand grew. The debate centered on whether there should be a change in consensus rules (requiring a hard-fork) to increase the block size limit (then capped at 1 MB) to allow more transactions per block, or to keep it small to preserve decentralization. On one side of the debate were large miners and businesses pushing for bigger blocks to reduce transaction fees and to increase transaction throughput on-chain. On the other side were node operators, developers, and users advocating for smaller blocks to ensure that anyone could run a full node, preserving Bitcoin’s censorship resistance and decentralization, allowing the fee market to self regulate and scale transaction throughput on future secondary settlement layers.
Arguments for smaller blocks emphasized that larger blocks would raise the cost of running a node (more storage space required), concentrating power in fewer hands. A block is formed, on average, every ten minutes, and a block is capped at a certain size. Therefore, how quickly the amount of computer storage is required to store the entire history of Bitcoin is fairly predictable to measure. If the blocks become bigger, then the memory required accordingly grows quicker. Those who champion Bitcoin as a decentralized protocol want the software to be usable by most around the globe. When Bitcoin requires less memory, it is then easier for those in more impoverished areas to still use it. When bigger, it may leave the less powerful with less sovereignty and influence.
Bitcoin is fundamentally a network protocol. As such, the ‘big blocker’ group was free to create their alternative version, now called Bitcoin Cash. Ultimately, however, it was the collective decision of the community and the market that determined which network would be adopted. This process became a contest between miners (large companies) and node operators (everyday users).
The nodes ultimately prevailed because they enforce Bitcoin’s consensus rules. While miners produce blocks, nodes reject any that violate these rules. Bitcoin’s elegance lies in its incentives: miners can mine any block they choose, but if network nodes deem it invalid under consensus rules, they will refuse to propagate it. Consequently, the block gains no legitimacy, and the miner forfeits the coinbase reward (newly minted bitcoin). Given the significant cost of mining, a miner has no financial incentive to create invalid blocks. Why expend resources mining a block no one will pay for?
This David vs Goliath story was evidence to the world that Bitcoin was very antifragile. Even when the rich and powerful businesses attempted to co-opt the network and change consensus rules, the nodes proved more powerful. It is evidence that, in matters of deciding what is a legitimate transaction on Bitcoin, it requires consensus from the node runners and everyday users.
The compromise following the scaling debate was the activation of the Segregated Witness (SegWit) softfork upgrade in 2017. SegWit improved efficiency by separating signature data (witness data) from transaction data. While the 1 MB limit for base transaction data remained, an additional ~3 MB could now be used for witness data. This effectively raised the block size limit to approximately 4 MB. The graph below shows block sizes from the network’s inception until SegWit’s activation.
Image source: https://data.hashrateindex.com/network-data/blocks
Here is another graph from the time SegWit was activated, up until January 14, 2023.
Image source: https://data.hashrateindex.com/network-data/blocks
As you can see, after SegWit was activated, blocks were allowed to become bigger than 1 MB, but rarely grew beyond 1.4 MB, despite the maximum being 4 MB. This upgrade simultaneously provided tremendous benefits to the network. This paved the way for the Lightning Network and further Layer 2 scaling which allowed for far greater transaction throughput on Bitcoin than Bitcoin-Cash could ever achieve on-chain.
SegWit’s introduction remains highly relevant to current debates. On January 14, 2023, a developer discovered how to inscribe data into Bitcoin transactions, creating ‘Ordinals’—effectively Bitcoin-based NFTs. This technique allows users to associate images and create tokens using Bitcoin transactions indirectly. Crucially, Ordinals leverage the witness data space (the ~3 MB allowance created by SegWit) made accessible through the Taproot upgrade. The graph below shows the entire history of Bitcoin block sizes up to today:
Image source: https://data.hashrateindex.com/network-data/blocks
A large spike in Bitcoin block sizes occurred when Ordinals were introduced to Bitcoin. Now blocks average somewhere around the 1.5 MB range.
Current Filters Debate
Today’s debate stems directly from compromises made during the Bitcoin block size wars. The Ordinals protocol stores inscription data within the witness data section of transactions, made possible by the SegWit upgrade and later leveraged by Taproot’s flexibility. Crucially, transactions using OP_RETURN or non-standard scripts for data larger than ~80 bytes are typically not relayed by default nodes adhering to standard relay policies. This is central to the issue. Bitcoin relies on nodes broadcasting transactions to peers (storing them in their mempools) until they propagate across the network, eventually reaching miners. Miners then build blocks from transactions in their mempools. Nodes will accept and validate any transaction within a block that follows consensus rules, regardless of size – large data transactions can be perfectly valid under consensus. However, if nodes filter out large non-standard transactions (>80 bytes) at the relay stage, a massive 1 MB data transaction might never reach a miner’s mempool, as nodes refuse to propagate it. This is one reason why Ordinals utilize the witness data space – it bypasses the standard relay filters applied to the base transaction data, as OP_RETURN is counted towards transaction data. The resulting concern is that witness data, which can occupy up to ~3 MB per block, accelerates blockchain growth if heavily used for large inscriptions. Recognizing that miners are including these large witness-data transactions in blocks, Bitcoin Core developers are moving towards raising the default relay filter size and potentially ceasing users’ ability to configure stricter filters. This aims to ensure nodes maintain a more consistent view of the mempool network-wide.
The above mentioned structure of filters works if Bitcoin mining is decentralized. Today, bitcoin mining is dominated by two major pools: Foundry USA and AntPool. While going on mempool.space might make it seem as if there is a more diverse set of pools, recent investigation has revealed that many large mining pools are all proxy pools for AntPool. Meaning, a large majority of mined blocks are mined by these two entities, and a handful of other big actors. This leads to a conundrum regarding large transactions: the Ordinal (or similar) transactions, by their very nature of being large, pay very well. A miner is incentivized to mine them. Additionally, because pools are so big, and an Ordinal user can be assured that a certain entity will mine a block within a reasonable time frame, they can bypass the node network filters and go straight to the miner. This is exactly what MARA took advantage of. MARA, a miner with 4.3% of the network hashrate, introduced Slipstream, which allows users with large transactions to go straight to them, thereby bypassing all filters operated by node runners.
A primary motivation behind Bitcoin Core’s push to raise (or potentially eliminate) transaction relay filters is to prevent mempool fragmentation. When nodes apply inconsistent filtering policies—like blocking large OP_RETURN data—they create divergent views of network activity. This fragments the mempool, giving users an incomplete picture of fee pressure and hindering accurate fee estimation. Additionally, maintaining configurable filters that contradict miner behavior introduces technical debt and creates a ‘false sense of control’—users might think they’re blocking ‘spam,’ but miners include these transactions anyway, undermining the utility of filtering. Crucially, Core argues that if large data is permitted by consensus, relay policies should reflect reality (miner acceptance) rather than impose subjective ‘legitimacy’ tests.
This decision has enraged many in the Bitcoin community, and rightly so. Filling the Bitcoin timechain with non-financial data could prove problematic. Firstly, the witness data is a roundabout way of having a protocol associate a transaction with a picture, while not involving placing the literal data of the picture on the chain itself. If the entirety of OP_RETURN is more easily accessible for use, then an entire picture may be stored directly. Essentially making it easy for Bitcoin to be used as a file-storage network up to 1 MB. Consequently, some argue that this opens the door for illicit content being stored on the network, which could provide an attack vector for governments, as everyone’s node would be a storage device for this illicit material. Lastly, no user appreciates being told that they might lose their ability to configure the node for themselves. This has led to a large portion of the community moving away from running Bitcoin Core to running Bitcoin Knots: an alternative implementation created by Luke Dashjr which is associated with the Ocean pool project. This node implementation maintains filter rules, and allows for greater configurability. While a year ago (late 2024) very few users ran Bitcoin Knots, it now commands a 21.59% share (at the time of this writing) of the total node network.
On Spam
While it is encouraging to watch the Bitcoin network gather around principles of decentralization and enhancing the monetary properties of Bitcoin, there are some considerable issues with the logic that simply changing node implementations will fix the issue regarding the rise of non-transactional data being placed on Bitcoin. Within the dialogue of this debate, this non-transactional data is being referred to as “spam”. However, this is sometimes done so in a very value-subjective manner.
Any user of the internet is aware of and dislikes spam. This is no different in the Bitcoin community: few people that I speak to want spam on the network. However, not all non-transactional data should be considered spam. Bitcoin is the invention of the world’s first unhackable network. It is a place where humanity can store data, and not worry about it being tampered with, hacked, or lost. This can be incredibly valuable for the recording of wills, government archives, and so on. Open Time Stamps, for example, is a project that is holding the governments of the world accountable for elections, maintaining records, etc. All through the use of this immutable ledger. The permanent record of these documents can surely be considered valuable to some. Some large transactions are also valuable in other ways, such as privacy preserving CoinJoins. That being said, most can likely agree that some data (such as child pornography) can easily be considered spam and is unwanted on this network.
Furthermore, there’s an underlying tension at the heart of this entire debate. On one side, Bitcoin Core developers argue that the legacy relay filter (the 80-byte OP_RETURN limit) no longer serves its purpose. After all, large Ordinal transactions are already being mined and use witness data, which suggests the filters have failed to stop them and only add unnecessary complexity to the codebase. On the other side, critics point out that those same filters did shape behavior, and this is why inscriptions use the witness data field instead of the OP_RETURN section. In other words, the filters may not have prevented Ordinals from existing, but they did influence how they exist. Both views have their merits, further exemplifying the complexity of the topic.
The Hard Truth of the Issue
Fundamentally, Bitcoin operates independently of personal opinions—whether mine, yours, or any user’s view of what constitutes ‘spam.’ During the block size wars, the network collectively accepted the SegWit upgrade, followed later by Taproot. Consequently, if a miner includes certain data in a block, every node—regardless of its filter settings—must recognize it as a valid transaction in the blockchain. Ultimately, this issue is less about individual preferences and more about miner-driven network dynamics.
As mentioned previously, Bitcoin mining pools are centralized. Semantically, there is a difference between a ‘miner’ and a ‘hasher’. A Bitcoin miner is a person (or entity) that operates ASIC machines, produces hashrate, creates block templates, and mines blocks through their own node. They both produce hashrate and choose what transactions go into their blocks. A hasher is simply someone who operates their ASIC machines but delegates the block creation to a pool. There are many hashers in the world, and very few miners.
The small number of actual miners leads to the ability for large transactions to be included in blocks because those users go directly to a large pool, bypassing network filters. This is fundamentally why Core developers began to pivot. Unless the number of miners (in contrast to hashers) grows, then what node runners choose to do does not ultimately decide what gets included into blocks.
Unfortunately, many in the community seem to be stuck in the mindset of the block size wars. It is as if the war cry of “my node, my choice” echoes across the years, without people noticing that this debate is not a question of consensus, and therefore they unfortunately hold less power in this circumstance. In matters of consensus, nodes hold significant influence. In matters of filtering, when mining is decentralized, nodes also hold significant influence. Neither is true at this moment in time. We’re stuck debating whether filters “work,” when the reality is paradoxical: they both do and don’t at the same time, because the current situation is influenced by other factors of the network that are currently suboptimal.
DATUM and StratumV2
The objective to decentralize and diversity block creation is essential if the network is to maintain its censorship resistance while simultaneously allowing the common people (the node runners) to maintain influence over what gets included into blocks. There are two key projects that both aim to achieve this goal: StratumV2 and DATUM.
Stratum is the initial protocol that made pools possible. However, under V1, mining pools have total control over block templates. Individual miners simply provide hashpower to validate work chosen by the pool. This gives pools de facto power to decide which transactions are included or excluded from the timechain. Stratum V2 was conceived as the fix for that imbalance. Originally proposed around 2019, SV2 introduced a new feature called job negotiation, which allows individual miners to construct or approve their own block templates rather than blindly hashing whatever the pool sends. In theory, this restores censorship resistance at the transaction-selection layer because individuals who operate machines can move away from simply being a hasher and become more like a miner once again. However, despite years of development and refinement, SV2 adoption has been slow. As of the time of this writing, no significantly large pool primarily uses SV2.
That gap in adoption gave rise to new initiatives like Ocean (previously known as Alegias), a mining pool founded by Luke Dashjr (creator of Bitcoin Knots) that explicitly focuses on decentralization and transparency. Ocean acts as a pool that encourages miner choice by integrating with software like DATUM, which enables miners to independently build blocks rather than rely on centralized templates.
This becomes crucial within the current conversation of filters. Miner diversification would make the enforcement of filters far more efficient. Currently, the best way a small-to-medium size miner can participate in block creation (while avoiding solo mining) is to mine with Ocean using DATUM. While beyond the scope of this article, there is also reason to expect that pools such as Ocean will become more competitive, and be more profitable, than FPPS pools as more halvings occur (read more here). Meaning, this decentralization of mining may occur naturally over time as halvings progress. While Ocean (at the time of this writing) is responsible for only 1.24% of the network’s hashrate, this share of the network may grow more and more. The question will then be: will DATUM users choose to preferentially use Knots or Core?
The importance of Financial Filters
The fact is that we are not currently in an environment where block template creation is diverse. While both Core and Knots will maintain filters and configurability, for now, non-financial transactions are still occurring and there is utility in contemplating how Bitcoin as a censorship-resistant decentralized network remains a predominantly monetary one. This is where I greatly appreciate the insights of Adam Back.
Adam Back is famous because he was cited in the Bitcoin white paper, primarily for his invention of a proof-of-work system in his project Hashcash. Hashcash was developed in the late 1990s as a way to combat email spam — not by filtering or banning senders, but by introducing a small computational cost to every message. Before sending an email, the sender’s computer had to perform a small amount of work, generating a hash that met a certain difficulty target. For normal users, that cost was negligible. But for spammers trying to send millions of emails, the accumulated computation became prohibitively expensive. In essence, Hashcash attached a financial or energetic cost to communication, transforming unlimited spam into an economically bounded activity.
In a world where miners are incentivized to mine blocks that pay the most, even if mining is decentralized, there will be economic incentive for the filters miners use to be lighter. Even if all nodes have filters and are configurable, there is no guarantee that node operators always maintain stringent filters. The most powerful method of eliminating most, if not all, spam is for the transaction fees to be prohibitively expensive. The only way that happens is if Bitcoin activity increases, and bitcoin is used as money more often.
This also highlights the uncertainty of the entire subject of spam: it is uncertain the timeline of when miners become diverse once again, it is uncertain what the general configuration of filters will be of the nodes on the network, and the timeline for increased network activity and transaction fees is also uncertain. Each factor can play a significant role in reducing spam, but no one knows the future.
A final observation on this point: many proponents in the Core vs. Knots discourse champion Bitcoin strictly as a monetary protocol, arguing it should exclude non-financial use cases. Ironically, one of Bitcoin’s most powerful spam filters already exists: economic activity itself. Transactions paying competitive fees naturally crowd out low-value data. Yet here lies the tension—while many advocate for Bitcoin as money, most users predominantly hold it as savings rather than transacting daily. A gentle reminder: if we truly want Bitcoin to thrive as a monetary network, we must use it as one.
Takeaway
Hopefully at this point, a clearer understanding has been created about the dynamics and discussion at play. Furthermore, while the discussion and division within the community may hold historical comparisons to the block size wars, the technical nuance is far different. While node choice plays a role in filtering out spam, this discussion is not one surrounding consensus. Voting with your node is less powerful here than it was during that time. Those who feel very passionately about Bitcoin, and wish to prevent spam from filling the network have two powerful means to enact change at their disposal: spend and mine bitcoin. Voting with your node still matters, but voting with your energy and your wallet matters more.
Using Bitcoin monetarily in daily life isn’t just beneficial—it’s critical to the network’s health. When transaction volume rises organically, fees naturally increase, pricing out opportunistic spam. While voting with your node has value, voting with your wallet has greater impact: economic activity is Bitcoin’s ultimate immune system.
Additionally, at this point of time, voting with your miner is more powerful than voting with your node. Bitcoin mining needs to decentralize, and the small number of true miners today needs to be healed. If you feel strongly that these types of transactions should not be included in a block, do your part to mine your own blocks. Solo-mine with a Bitaxe, mine with a host and point towards Ocean using DATUM, or start a bitcoin mining company yourself. In this case, actions will speak louder than words. Vote with your energy, not just with your software.
