Bitcoin SpamWhy We CAN Stop It
Bitcoin has a network effect as money because users keep choosing it for the advantages it has over other monies. Pictures, tokens, non-monetary contracts and arbitrary file storage in its blocks can reduce the emergent monetary properties that come from those choices. Spam is neither inevitable nor unstoppable. It results from the choices that protocol rules allow, and different choices and protocol rules can move Bitcoin toward its role as money or away from it. Divergent uses can create non-monetary emergent properties that displace or override some of its monetary ones, so limiting them helps Bitcoin remain money.
Both loops run on the same rules. Choose a side above to see which loop the rules feed.
Bitcoin is money because people use it as money
No one decreed that Bitcoin is money. It became money the way every money has: people found it useful for trade, more people accepted it because others did, and that network effect fed on itself. Its monetary role is an emergent property. It lasts as long as the qualities that produced it stay intact.
Economists usually list six properties that make something good money. Bitcoin adds a seventh that no earlier money could offer: immutability through decentralization. Here is each property, and how non-monetary use can affect it.
Durability
Money has to last. Bitcoin's ledger lasts because many independent people keep and verify it. Data written to the chain stays there permanently, and data hidden in unspendable outputs stays in the set of coins every node holds in fast storage. Both add to the long-term cost of keeping the ledger.
Portability
Money has to move easily. The cost of moving bitcoin is set by the market for transaction space. When non-monetary demand enters that market, the cost of moving money depends partly on markets that have nothing to do with money.
Divisibility
Money has to be usable in small amounts. The smallest amount worth spending depends on what a transaction costs. Whatever sets that cost for non-monetary reasons also sets, for non-monetary reasons, how small a usable amount of bitcoin can be. This is one way that a money scales.
Uniformity
Every unit of money should be as good as any other. Inscription protocols number individual satoshis and treat some as collectibles. Wallets that follow them must track particular coins and avoid spending them, so equal amounts stop being equal. Also referred to as fungibility. This is one way that a money scales globally.
Scarcity
Non-monetary use doesn't touch the 21 million cap. That cap is enforced by the nodes that verify every block, so it is only as secure as the seventh property below.
Acceptability
Money is accepted because others accept it. That is the network effect itself. A reputation as a permanent file store, and open questions about responsibility for files stored on chain, give some people reasons not to accept, hold or support Bitcoin.
Immutability through decentralization
No one can rewrite Bitcoin's history because no one controls enough of the network to do it. That depends on many independent people being able to verify the whole chain. Permanent non-monetary data adds to what each of them must verify, and costs like that fall hardest on the smallest operators.
File Sharing Networks Are Useful For Data
Money isn't the only thing that emerges from a network. File sharing networks such as BitTorrent, IPFS, Filecoin and Arweave are built around a different set of properties. Here are eight that make a network good at sharing files. Most of them pull in the opposite direction from the properties of money, which is why storing data in Bitcoin diverges from its role as money.
Durability
Files survive over time because enough copies exist somewhere. Durability is never free: every copy has to be stored, powered and moved to new hardware for as long as the file exists, so its cost keeps growing with time. File networks handle this by charging for storage or letting operators choose what to keep. In Bitcoin, whoever stores a file pays once, and the network's full nodes carry the cost of keeping it with no end date.Shared with money, but money needs every node to keep one small ledger, not every file anyone chooses to add.
Availability
Anyone can fetch a file quickly, at any time. File networks spread popular files across many hosts so downloads stay fast.Money only needs recent transactions to move quickly. Its older history only has to stay verifiable.
Capacity
The network can hold more and more data as demand grows.The opposite of what money needs. The ledger has to stay small enough for ordinary people to verify on their own.
Low cost per byte
Storing and sharing a file should be cheap. That holds only in the short term. The cost of durability grows every year a file is kept, so a low price to store it today isn't a low cost over the file's life.In money, the cost of adding data is what keeps the ledger small.
Selective hosting
Each operator decides which files to store and share. A BitTorrent user seeds only what they choose, and an IPFS node keeps long term only what it pins.Money works the opposite way. Every node must accept every valid block, so no node can turn down a file inside one.
Deletability
Files can be removed for legal, safety or personal reasons.Money needs the opposite: immutability, so that no record can be removed or changed.
Access control
Owners decide who can read a file, often by encrypting it or limiting who can fetch it.Bitcoin has none. Data written to it can be read by anyone who downloads the chain, and nobody can later restrict who reads it.
Integrity
You get exactly the file you asked for, unaltered. File networks do this by naming each file after a hash of its contents.Shared with money. Bitcoin's hashing makes any change to its history detectable.
Only durability and integrity overlap, and even those work differently. The rest are opposites: rules that would make Bitcoin a better file network would make it a worse money.
When uses diverge, new properties emerge
The last two sections described two sets of properties. Monetary properties emerge when people use Bitcoin as money. File sharing properties are what a network needs to be good for data. Both pull on the same rules. When Bitcoin is used for data, the rules get pulled toward the second list, and properties emerge that money never needed. That's what the thesis means by divergent uses.
File sharing isn't the only non-monetary use. Tokens, collectibles and non-monetary contracts pull in their own directions too. Here are five (of many) divergent properties that have already emerged, where each one comes from, and the monetary property it pushes against.
A permanent public file store
Comes from: File sharing's need for durability, without selective hosting, deletability or access control
Pushes against: Acceptability
Once Bitcoin is known as a place where any file can be stored forever, it inherits every responsibility that comes with hosting files, including forcing node runners to re-share files without their consent. There is no way to un-share a particular file: blocks are checked and passed on whole, so a node can't drop one file and keep the rest. Even pruned nodes will force users to share the most recent files, regardless of content. These responsibilities have nothing to do with money, but they shape whether people choose to use the network for money.
Collectible coins
Comes from: Inscription and token protocols that treat satoshis as items, not money
Pushes against: Fungibility and divisibility
When individual satoshis are numbered and traded as collectibles, some coins become worth more than others of the same amount. Money depends on the opposite being true. A collectible satoshi also has to travel with other sats in the same output, and wallets usually freeze that whole output rather than risk spending the collectible by mistake. Those extra sats can no longer be split off and spent freely.
Income That Depends On Data
Comes from: Demand for capacity and low cost per byte turned into revenue
Pushes against: Fungibility and divisibility, through centralization
Miners, marketplaces and services that earn from non-monetary demand have a reason to oppose rules that favor monetary use. Every fee a pool earns from inscriptions and runes is revenue that a spam-limiting rule would take away, so pools have a built-in reason to oppose such rules. Also, paid submission services (a.k.a. super relays) earn income by delivering transactions that most nodes' relay policy would filter, straight to miners. That income is a divergent network effect of its own. It grows with non-monetary demand and weakens fungibility and divisibility, two of the ways a money scales.
Costs set by speculation
Comes from: Token launches and collectible mints
Pushes against: Portability and divisibility
Token launches and collectible mints come in waves. During them, the price of moving money is set partly by speculative cycles that have nothing to do with payments.
Contracts that need intermediaries
Comes from: Non-monetary contracts
Pushes against: Portability, fungibility and acceptability, through centralization
If covenants were introduced, most people would likely use them through third-party services, because building and checking covenant contracts yourself is too complex for the average user. Contracts that tie coins to conditions, such as insurance arrangements, also make those coins harder to move or exchange freely. Coins held under different conditions stop being interchangeable with free coins, and depending on intermediaries brings back the trust that Bitcoin as money removes.
Every example follows the same pattern: a non-monetary use pulls the rules toward what it needs, and a property of money gives way.
Spam doesn't have to break Bitcoin to hurt it. It only has to grow properties that make Bitcoin a little less useful as money, until people choose something else.
Paying for space doesn't make a use monetary
A common view is that the fee market alone should decide what enters a block: if a transaction pays, it belongs. Bitcoin has never worked that way.
Consensus rules reject transactions that break them, whatever fee they offer. Relay policy has long declined to pass on transactions that are valid but non-standard. Outputs too small to be worth spending have been non-standard since 2013. Each of these puts something other than price in charge of what gets in.
Fees decide the order of transactions the rules allow. The rules decide what is allowed. Whether Bitcoin's rules should favour its use as money is a question fees can't answer, because it's a question about the rules themselves.
Paying for block space does not make a transaction's purpose monetary.
How data gets in
Non-monetary data enters Bitcoin in at least nine ways. They differ in how much data fits, what it costs and how much harm it does. Each exists because of what the rules allow, and each can be resisted, though not always stopped, by node settings or consensus rules.
| Method | How it works | What the rules allow | Price per byte | Properties affected | What can resist it |
|---|---|---|---|---|---|
| OP_RETURN outputs | Data goes in an output marked provably unspendable. Runes, Omni and Counterparty use this route. | Kept out of the set of spendable coins, so it can be pruned. Bitcoin Core's default relay limit was 83 bytes until version 30 (October 2025) raised it to 100,000 bytes and allowed several per transaction. Knots keeps 83 bytes. | Full price | Durability, as permanent chain growth pushes more node runners to prune, leaving fewer full copies of the history; fungibility when a token protocol like Runes uses it | Policy: -datacarriersize, -datacarrier=0, Knots -rejecttokens. Consensus: a cap on the size of new outputs. |
| Witness envelopes | Data is wrapped in a never-executed OP_FALSE OP_IF … OP_ENDIF block inside a Taproot script. Inscriptions and BRC-20 tokens use this route. |
Up to about 400 KB in a transaction relayed by default, and nearly 4 MB if a miner includes it directly. | 75% discount | Uniformity, durability, & immutability through decentralization | Policy: Knots -rejectparasites and -maxscriptsize. Consensus: a cap on data push size, or a ban on conditional branches in Taproot scripts. |
| Fake multisig keys | Data is disguised as public keys in bare multisig outputs that can never be spent, as with classic Stamps. | Each output holds under 100 bytes, but a transaction can have many. The data stays in the set of spendable coins that every node holds, permanently. Relayed by default in Core, not in Knots. | Full price | Durability & immutability through decentralization | Policy: -permitbaremultisig=0 (the Knots default). Consensus: a cap on the size of new outputs. |
| Fake ordinary outputs | Data is split across outputs that look like normal 32-byte script hashes or keys, as with the newer OLGA format used by Stamps. The outputs can never be spent. | Up to about 65 KB per transaction. The data stays in the set of spendable coins permanently, and each output looks like a normal payment. | Full price | Durability & immutability through decentralization | Policy: Knots -rejecttokens detects the OLGA pattern. Consensus: hard to target, because the outputs look like ordinary ones and fit any output size cap. |
| P2WSH witness scripts | Data is placed in the witness script of a SegWit version 0 spend. | Up to 3,600 bytes per input under default relay policy. | 75% discount | Durability | Policy: Knots -maxscriptsize. Consensus: a cap on data push size. |
| Legacy input scripts | Data is placed in the unlocking script (scriptSig) of an older-style input. | Up to 1,650 bytes per input under default relay policy. | Full price | Durability | Policy: Knots -datacarrierfullcount applies its data limits beyond OP_RETURN. Consensus: a cap on data push size. |
| Large Taproot control blocks | Data is hidden in the proof that a script belongs to a Taproot script tree. | Up to about 4 KB per input. | 75% discount | Durability | Policy: no common setting. Consensus: a cap on control block size. |
| Upgrade hooks | The Taproot annex, unknown witness versions and reserved OP_SUCCESS opcodes exist for future upgrades, and can carry data. |
Valid under consensus, up to the block limit, but not relayed by default. A miner can still include them directly. | 75% discount | Durability | Policy: already non-standard in Core and Knots. Consensus: make them invalid until an upgrade needs them. |
| Steganography | Data is hidden in normal-looking fields such as signatures, keys, amounts and lock times. | A few bytes per transaction. Relayed like any payment. | Normal price | Negligible | Nothing can detect it, but the amounts are too small to matter. |
Settings that resist it
Node software offers settings that decline to relay or mine some of these methods. They only affect your own node, and they're bypassed when transactions are sent straight to miners. They raise the cost and narrow the path, but they don't bind blocks.
| Setting | Software | What it resists | Default |
|---|---|---|---|
-datacarriersize | Core and Knots | Large OP_RETURN outputs | Core 30: 100,000 bytes. Knots: 83 bytes |
-datacarrier=0 | Core and Knots | All OP_RETURN outputs | Allowed |
-permitbaremultisig=0 | Core and Knots | Fake multisig keys | Core: allowed. Knots: blocked |
-rejectparasites | Knots | Detectable overlay protocols, such as inscriptions | On |
-rejecttokens | Knots | Token protocols, including Counterparty and OLGA Stamps | Off |
-datacarriercost | Knots | Counts data bytes as heavier when ranking transactions | 1.0 (no extra weight) |
-datacarrierfullcount | Knots | Applies data limits to methods beyond OP_RETURN | On |
-maxscriptsize | Knots | Large scripts and witness stacks | Varies by version |
-dustrelayfee | Core and Knots | Tiny outputs used to bloat the set of spendable coins | 3 sat/vB |
Consensus limits that have been proposed
Consensus rules are the only layer that binds every block, however a transaction arrives. Limits that have been proposed include capping new outputs at 34 bytes (83 for OP_RETURN), capping data pushes at 256 bytes, limiting Taproot control blocks, banning conditional branches in Taproot scripts, and making upgrade hooks invalid until an upgrade needs them. Even these leave gaps. Data can be split into smaller pieces at a higher cost, and fake outputs that look like ordinary ones are hard to target.
No single setting or rule stops every method, but each layer raises the cost of using Bitcoin for data.
Example: Rules set the price of data
SegWit (BIP 141) counts witness bytes at a quarter of the weight of other bytes. The discount was designed so that spending coins would cost less than creating new ones, which keeps the set of spendable coins small. Taproot's script rules (BIP 342) removed the old limit on script size. Together, those two rules made the witness the cheapest place to store large files. Move the sliders to see the difference.
A simplified estimate that ignores the small transaction overhead. Data in an OP_RETURN costs 1 vbyte per byte. Data in a witness costs a quarter of a vbyte per byte.
Where the choices are made
Spam results from the choices that protocol rules allow. Those choices happen at four levels, and they aren't equally powerful. Being honest about which ones work is part of making the case.
Everyone, through consensus
Protocol rules
Can: bind every block, no matter how a transaction reached the miner. Rules set what data costs and how much of it a transaction can carry.
Can't: change without broad agreement from the people and businesses that run nodes and hold bitcoin. BIP-110 failed because it didn't have that agreement.
Protects: all seven monetary properties
Miners and pools
Block templates
Can: decline to include transactions. Protocols like DATUM, used by the OCEAN pool, let individual miners build their own templates with their own policies.
Can't: keep data out while other miners include it. As long as the rules reward it, some miners will take the fees.
Protects: portability, divisibility
Node runners
Relay policy
Can: decline to pass on transactions and show which policy users prefer. Bitcoin Knots offers filters for common data patterns.
Can't: stop transactions sent straight to miners or through relay services that accept them. Relay policy alone doesn't keep spam out of blocks.
Protects: a signal, not a guarantee
Wallets, exchanges and users
Demand
Can: decline to build, list or promote non-monetary schemes, which reduces the market that pays for them.
Can't: remove the incentive while the rules still make data storage cheap.
Protects: acceptability, uniformity
That's why this page focuses on the emergent properties of money and the rules that shape them. Miner and relay choices help at the margins, but the lasting fix is a consensus-driven rule change with broad support. Broad support comes from making the monetary case clearly enough that people who run nodes, hold bitcoin and mine blocks agree with it.
Rules have changed before
Bitcoin has two kinds of rules. Consensus rules decide which blocks are valid, and every node enforces them on every block. Node policy decides what a node relays and what a miner puts in its block template by default. It can differ from node to node and doesn't bind blocks. Most entries below are one or the other, and each changed behaviour. Some moved Bitcoin toward its role as money. Others opened doors nobody intended. Two entries aren't rule changes at all, but new uses that followed from earlier ones.
| Year | What changed | Type of change |
|---|---|---|
| 2010 | Satoshi adds a 1 MB block size limit. It is widely understood as a guard against spam and denial-of-service attacks. SegWit later replaces it with a weight limit. | Consensus |
| 2013 | Bitcoin Core 0.8.2 makes "dust" outputs, too small to be worth spending, non-standard. | Node policy |
| 2014 | Bitcoin Core 0.9 makes small OP_RETURN outputs standard. The aim is to give data a prunable place that stays out of the set of spendable coins. The limit later settles at 80 bytes of data. | Node policy |
| 2017 | SegWit activates and counts witness data at a quarter of the weight of other data. | Consensus |
| 2021 | Taproot activates, and its script rules remove the old script size limit. | Consensus |
| 2023 | Ordinals inscriptions combine those two changes to store large files cheaply. In February a single inscription takes up 3.96 MB of block 774,628. | New use, no rule change |
| 2024 | Runes tokens launch at the April halving, using OP_RETURN outputs. | New use, no rule change |
| 2025 | Bitcoin Core 30 raises its default OP_RETURN relay limit from 83 bytes to 100,000 bytes. | Node policy |
| 2026 | BIP-110, a temporary soft fork to limit data, fails. About 2.5% of blocks signal for it against a 55% threshold, and the minority chain stalls after two blocks. | Consensus (proposed) |
BIP-110 didn't show that spam could be stopped. It showed that one design to reduce spam, at one moment, didn't win enough agreement. Rules that move Bitcoin toward money have been adopted before, and rules that moved it away were adopted too. Which way the rules move next depends on which argument persuades more people.
The strongest objections, answered
These are the arguments most often raised against changing the rules, with a response to each.
"Filters don't work. Spammers just go straight to miners."For relay filters on their own, that's largely right.
Transactions can be sent directly to miners, and some relay services accept what filtering nodes refuse. That's why this page doesn't rest its case on filters. Consensus rules apply to every block, however a transaction arrived.
"Fee demand should be the only thing that decides what goes in a block."It never has been.
Consensus rules, standardness and dust limits have always excluded transactions that were willing to pay. Fees rank what the rules allow. They were never meant to decide what the rules should be. See paying for space doesn't make a use monetary.
"Miners like higher fees. Spam pays them more."True today, and worth taking seriously.
Miners are paid in bitcoin, and the value of what they're paid rests on Bitcoin's use as money. Fee income from uses that weaken the monetary properties is a trade-off, not a free gain. Each miner has to weigh short-term fees against the long-term value of the coins they earn.
"I don't care what goes in the blocks. I care about earning the fee, not what the block contains."The fee and the data aren't separate.
The fee is paid in bitcoin, and what that bitcoin is worth rests on its use as money. If the data in a block weakens the properties that make Bitcoin money, some of the fee's value goes with them. The data also doesn't go away once the fee is collected. Every node downloads, verifies and passes it on, whatever it contains, and the chain keeps it permanently. Caring only about the fee is still a choice, and under the current rules it's a choice that rewards non-monetary use.
"If you block one method, they'll hide data somewhere worse."Rules still set the price of every method.
No rule can stop every way of disguising data. But methods differ in cost. Fake-key methods pay full price per byte, four times what the witness costs. The aim isn't zero. It's to stop the rules from making non-monetary data cheaper than monetary use, and to address worse methods as they appear, as past rule changes did.
"Who decides what counts as spam?"The same process that decides every other rule.
Bitcoin's rules already draw lines around valid transactions, standard scripts and dust. Any new line goes through the same open process of proposal, review and adoption as every earlier one.
"Changing the rules to restrict data is censorship."A rule that applies equally to everyone isn't censorship.
Censorship resistance in Bitcoin means no one can stop a valid transaction from being confirmed. Immutability means no one can reverse or change it once it's final. Both protect transactions that follow the rules. Neither has ever promised that the rules themselves can't change.
Censorship singles out particular people or payments. A consensus rule applies the same way to every transaction and is adopted in the open. Bitcoin has changed its rules this way many times, including the changes that made data storage cheap in the first place.
"BIP-110 failed, so the debate is over."One proposal failed. The question didn't go away.
BIP-110 lacked support from miners and major economic nodes. That tells us what a successful change needs: a clear case and broad agreement. It doesn't tell us that rules favouring monetary use can never be adopted.
What a good proposal looks like
The objections above point to what a rule change needs in order to win. BIP-110 shows that a good idea isn't enough. Four tests, drawn from what this page has argued, separate a proposal that can earn broad agreement from one that can't.
It is narrow
It is neither a complete fix nor a bundle of fixes. No single rule stops every method, so a proposal that promises to is easy to reject. One that changes one thing is easier to review, test and explain, and it can't be voted down because of a part someone dislikes.
It targets the biggest harms first
Methods differ in how much data they carry, what they cost and how much damage they do to the monetary properties. Start with the ones that do the most harm, and address worse methods as they appear, as past rule changes did.
It has a clear activation path
Everyone who must agree, from the people who run nodes to the miners and businesses, can see how the change would activate, what threshold it needs and what happens to anyone who doesn't upgrade. A rule with no agreed way to switch on gets stuck before it starts.
It can be reversed
A consensus change needs a plan for undoing it by consensus, whether that is an expiry date or a way to switch it off, if it causes harm nobody foresaw. The plan is part of the proposal from the start. Knowing that a mistake can be corrected makes it easier to agree to the change.
What you can do
Money is emergent. It exists because many people make the same choice, so your choices count.
Run your own node
Your node enforces the rules you choose. Rule changes succeed when enough of the people and businesses who use Bitcoin run nodes that enforce them.
Learn how rules set incentives
Read BIP 141 and BIP 342, and use the calculator above. Knowing why data is cheap is the first step to arguing that it shouldn't be.
Make the monetary case
In discussions, show with evidence how a particular use affects Bitcoin's monetary properties. Argue the ideas, not the people.
Take part in review
Read, test and comment on proposals on the mailing list and in pull requests. Specific feedback moves proposals further than outrage does.
Put your business where your view is
Choose wallets, exchanges and pools whose policies match the use of Bitcoin you want to support.
Read further
Check these primary sources yourself and form your own view.
- BIP 141: SegWit and the witness weight discount
- BIP 342: Taproot's script rules
- BIP 110: the Reduced Data Temporary Softfork, source of the proposed consensus limits above
- Bitcoin Core 30.0 release notes, including the OP_RETURN policy change
- Bitcoin Core 0.8.2 release notes, including the dust rule
- Bitcoin Knots: node software with data filtering options
- Bitcoin Knots v29.1 release notes, describing its data and token filters
- Bitcoin Knots configuration reference (Study Knots), listing policy settings and defaults
- Bitcoin Core
policy.h: default relay limits for scripts, witnesses and bare multisig - Bitcoin Core pull request #28217, a closed proposal to stop relaying bare multisig by default
- Bitcoin Stamps documentation, describing multisig and OLGA encodings
- Counterparty CIP33: file storage in P2WSH outputs
- OCEAN and the DATUM protocol for miner-built block templates
- Ordinals documentation describing inscription envelopes
- Coverage of BIP-110's failure (crypto.news)
- bitcoindev mailing list, where protocol changes are debated
- Bitcoin Spam by Stephan Livera, which argues the other side