|
Anti-phishing words: Harrier -
|
|
|
|
|
|
|
Hi ,
Bitcoin arguments often arrive wearing a technical disguise, which is convenient for everyone who would rather make normal people feel too stupid to care. A few unfamiliar words appear, someone mentions relay policy, consensus rules, OP_RETURN or soft forks, and most readers back away as if they have stumbled into a basement argument between developers.
The fight over Bitcoin Core and BIP-110 is not really about code, although code is where the argument happens. It is about what Bitcoin is for, who gets to decide that, and whether the network built to separate money from political and institutional control should slowly be trained into becoming a permanent storage layer for whatever someone can pay a miner to include.
|
 |
|
That distinction matters because Bitcoin is not a website. When some platform fills up with junk, the company can delete accounts, change its terms, hide the mess behind a new interface and pretend the problem has been “improved for your safety”. Bitcoin doesn't work like that. Once something is mined into a valid block, it becomes part of the history that serious users around the world must verify for themselves. It is no longer someone else’s little experiment on someone else’s server. It is now luggage handed to everyone running a node, because every valid block has to be downloaded, checked and stored as part of Bitcoin’s history.
For monetary transactions, that burden is the point. If you want money that doesn't need permission, someone has to verify the rules without asking a bank, a state or a Silicon Valley babysitter what the balance is supposed to be. But when Bitcoin blockspace is used for arbitrary data, inscriptions, token schemes, collectibles, metadata and the usual shitcoin glitter, the moral accounting changes. The person creating the transaction pays the miner, the miner takes the fee, and then everyone running a node inherits another piece of permanent debris.
|
 |
|
This is why the easy answer, “they paid the fee”, doesn't settle the argument. Paying a toll to enter the road doesn't mean you get to leave rubble on it forever and call that market discovery. Bitcoin’s blockspace is scarce, but scarcity alone doesn't tell us whether every paid use strengthens the monetary network or slowly turns scarce monetary settlement into paid storage for other people’s junk.
That is the real question under the Core versus BIP-110 fight. Is Bitcoin neutral infrastructure for anything that can squeeze into a block, or is it sovereign money with a purpose worth defending before the parasites learn to describe themselves as customers?
|
 |
|
The Difference Between a Filter and a Rule |
|
Before getting into the disagreement, it helps to understand the difference between a filter and a rule.
Bitcoin has many layers of decision-making, and not all of them carry the same weight. Some decisions affect what a node is willing to pass around before a transaction is mined. Other decisions affect what a node will accept as valid Bitcoin once a miner has produced a block. That difference sounds technical, but it is really the difference between saying, “I don’t want to help spread this”, and saying, “I don’t recognise this as part of Bitcoin”.
The first category is called relay policy. You can think of it as the standard a node applies to transactions that are still waiting to be confirmed. Those transactions sit in a kind of waiting room called the mempool, although there is no single mempool shared by everyone. Each node keeps its own version, according to its own rules. If a node decides a transaction is too large, too cheap or otherwise outside the policy it is willing to enforce, it can refuse to keep that transaction in its mempool and refuse to pass it on to other nodes. That makes the transaction harder to move through the normal peer-to-peer network, but it doesn't make the transaction invalid. If another path gets it to a miner, and the miner includes it in a consensus-valid block, the node that refused to relay the transaction before mining still accepts the block after mining, because the transaction never broke Bitcoin’s actual rulebook.
|
 |
|
Consensus rules are different. Consensus is Bitcoin’s hard rulebook. These are the rules your node uses when a new block arrives and asks to be accepted as part of Bitcoin’s history. Did someone spend coins they didn't have? Did the block break the rules that make Bitcoin Bitcoin? If the answer is yes, your node rejects it, no matter how confident the miner looks and no matter how many people are pretending everything is fine.
A simple example makes the difference clearer. Imagine a private members’ club. Relay policy is the doorman deciding who he is willing to recommend to the room. Consensus is the constitution of the club deciding who is actually a member. The doorman can be stricter or looser without rewriting the constitution. But if the members decide the constitution itself needs a new boundary, that is a much bigger decision, because everyone now has to agree what membership means. This is the distinction sitting underneath the Core and BIP-110 debate.
|
 |
|
Bitcoin Core v30 made the default relay policy more permissive toward transactions carrying arbitrary data. It did not change consensus. If a miner put one of those transactions into an otherwise valid block, nodes would still have to accept it. BIP-110 takes the other position. It argues that if miners are happy to sell blockspace for non-monetary junk, then filtering at the relay layer is not enough. It proposes a temporary tightening of consensus rules so that certain patterns of arbitrary data use would be rejected by nodes running the new rules.
That is the actual disagreement. Core is saying the network should honestly relay whatever miners are already willing to mine. BIP-110 is saying users have every right to draw a harder line when they believe miner incentives are pulling Bitcoin away from being sovereign money and toward being a general-purpose data layer.
|
 |
|
Neither position is trivial. A filter can be too weak if it only hides the problem while miners keep accepting the transactions anyway. A rule can be too strong if it is rushed, poorly coordinated or written so broadly that it catches uses the network didn’t intend to block. But pretending this is only about “spam” or “censorship” misses the point. The real argument is about where Bitcoin should place the boundary between tolerated behavior and invalid behavior.
Core is asking what the network should relay when miners are willing to sell the space. BIP-110 is asking whether some uses of that space should remain valid at all.
|
|
What People Are Putting Into Bitcoin |
|
The phrase “arbitrary data” sounds harmless, mainly because it sounds too boring to be dangerous. It doesn’t mean ordinary transaction information, like who is spending which coins, which signatures prove ownership, or which outputs receive the bitcoin. That kind of data is necessary. Without it, Bitcoin would not know who owns what, who has spent what, or whether a payment is valid. The argument is about something else.
Some people use Bitcoin transactions to publish data that is not needed for Bitcoin to function as money. That can mean images, text, metadata, token records, digital collectibles, files, experiments and all the familiar shitcoinery theatre that arrives whenever someone discovers a scarce resource and immediately tries to sell a casino inside it. These transactions may follow the rules. They may pay fees. They may even be profitable for miners. But they are using Bitcoin’s monetary settlement layer for a purpose beyond monetary settlement.
|
 |
|
Inscriptions are the most famous example. A simple way to understand them is that someone finds a way to tuck extra content into a Bitcoin transaction so that, once the transaction is mined, the content becomes part of Bitcoin’s history. The content can be “art”, text, token-related information or anything else that can be squeezed into the available structure. To the people doing it, this looks like innovation or clever marketing. To everyone else, it looks like another grift trying to ride Bitcoin’s reputation to extract money from fools. To the person trying to keep Bitcoin lean enough to verify from home, it can look more like someone discovering that the world’s hardest money also works as an extremely expensive noticeboard.
Bitcoin gets stronger when more people use it as money. More savers, more payments, more liquidity, more final settlement and more people holding their own keys all reinforce the monetary network. Bitcoin doesn’t become better money because more people use it to store collectibles, token metadata or digital debris. At best, those uses compete for the same scarce blockspace. At worst, they encourage businesses and speculators to treat the base layer as a permanent data product rather than a monetary network.
|
 |
|
This is where the debate becomes uncomfortable. Bitcoin’s rules don’t ask a transaction why it exists. A node doesn’t look into a transaction’s soul and decide whether it has pure monetary intentions. It checks structure, signatures, amounts and validity. If the transaction follows the rules and a miner includes it, the network doesn’t pause for a philosophical committee meeting.
That is precisely why the Core and BIP-110 argument exists. If unwanted data use can fit inside the rules, then the disagreement moves from taste to governance. One side says the network should accept that reality and manage it honestly. The other says the rules themselves may need a temporary boundary before a monetary system is gradually repurposed by whatever pays enough to occupy its scarce space.
|
 |
|
The question is not whether every byte outside a simple payment is evil. The question is whether that flexibility should become an open invitation for data businesses, token games and digital landfill to make themselves at home inside the base layer.
Bitcoin was not designed to make data permanent. It was designed to make money incorruptible.
|
|
What Core Actually Changed |
|
This is where the argument usually becomes messy, because people hear that Bitcoin Core changed something and immediately assume Bitcoin itself changed with it. That is not quite right.
Bitcoin Core is the most widely used Bitcoin node software. It is not Bitcoin itself, and nobody is forced to run it, but its defaults matter because many users, wallets, businesses and miners build around them. When Core changes what its software does by default, it can shape how transactions move through the network, even if it doesn't rewrite Bitcoin’s actual rulebook.
|
 |
|
The change at the centre of this dispute involved something called OP_RETURN, which is a way to attach data to a Bitcoin transaction in a form that is provably unspendable. In plain English, OP_RETURN is a bit like writing a note onto a transaction and making sure that note doesn't pretend to be spendable bitcoin. For years, Bitcoin Core treated that note field as something small. With Core v30, the default policy became much more permissive, allowing larger OP_RETURN data and multiple data-carrying outputs by default.
That sounds dramatic, and in one sense it is. But it is important to be precise about what kind of drama it is. Core did not make previously invalid blocks valid. It did not tell every node that Bitcoin’s consensus rules had changed. It changed the kind of data-carrying transactions the software was normally willing to pass around before those transactions were mined. That is relay policy, not consensus.
|
 |
|
Core’s best argument is that this reflects reality rather than endorses it. If people are already finding ways to put data into Bitcoin, and miners are willing to include those transactions, then refusing to relay them through the normal network may not stop the behavior. It may simply push users towards direct submission to miners or mining pools, or encourage more awkward ways of embedding data that create worse side effects than OP_RETURN. From Core’s perspective, it is better for node software to see and relay the kinds of transactions miners are already likely to include, rather than pretending those transactions have been stopped while they keep appearing in blocks anyway.
There is a practical logic to that. If a town knows people are dumping rubbish in the river at night, one response could be to create a monitored disposal site so the damage is at least visible and contained. Core’s position is similar: OP_RETURN is not perfect, but it is cleaner than forcing data users into tricks that make the UTXO set worse or hide the activity somewhere less transparent.
|
 |
|
That is the strongest version of Core’s case, and it should not be dismissed as “Core loves spam”. The better version is that Core thinks filters become counterproductive when miners and users have enough incentive to route around them. From that perspective, a node policy that pretends unwanted transactions won’t be mined can become less honest than one that admits what miners are already willing to sell.
But the objection remains obvious. A monitored disposal site may be better than people dumping waste in the river, but it still accepts the premise that waste disposal belongs in the town’s central square. Making the bin cleaner doesn't answer whether Bitcoin should be normalizing the business of filling that bin in the first place. That is where BIP-110 enters the argument.
|
|
Why BIP-110 Pushes Back |
|
BIP-110 looks at the same problem and reaches a very different conclusion.
Where Core says filters can become pointless when miners are willing to include the transactions anyway, BIP-110 says that is exactly why filters are not enough. If the only thing stopping unwanted data use is a node saying, “I won’t help pass this around”, then the transaction only needs another route to a miner. Once it gets mined into a valid block, everyone enforcing the existing rules accepts it.
From the BIP-110 perspective, that is not a real boundary. This is why BIP-110 moves the argument from relay policy to consensus. Instead of saying certain data-heavy transactions should be harder to pass around before mining, it says that, for a temporary period, blocks containing certain data-heavy patterns should not be accepted by nodes enforcing the new rule. That is a much stronger move, and it is supposed to be. The whole point is to stop treating arbitrary data as a messy customer-service issue and start treating it as a question about what Bitcoin should allow into its base layer.
|
 |
|
A simple way to think about it is the difference between refusing to deliver a package and changing what counts as acceptable cargo. Relay policy is the courier saying, “I’m not carrying this”. The package might still reach its destination through another courier. BIP-110 is closer to the port authority saying, “This type of cargo is not coming through this harbor at all”. That kind of rule is more serious, but it also deals with the problem at the level where the final decision is made.
BIP-110 proposes this as a temporary soft fork. In plain English, a soft fork is a tightening of Bitcoin’s rulebook. Old rules may have allowed a wider range of blocks, while the new rule says some of those blocks are no longer acceptable to upgraded nodes. In this case, the proposal would run for roughly one year and would restrict several common ways of putting arbitrary data into Bitcoin, including larger OP_RETURN data and certain script or witness patterns associated with inscriptions and similar systems.
|
 |
|
That last part matters because BIP-110 is not only about one technical field called OP_RETURN. OP_RETURN gets most of the attention because Core made that path more permissive by default, but inscriptions and other data systems can use different parts of Bitcoin’s transaction structure. BIP-110 tries to close several of those doors at once, at least temporarily, because its supporters believe the issue is bigger than one note field inside a transaction.
The underlying principle is straightforward. If Bitcoin is money, then its base layer should be protected for monetary use. Not every use of blockspace is equal just because someone can pay the fee. A transaction that moves value between two people is doing what Bitcoin was built to do. A transaction that turns the base layer into storage for token records, images or digital collectibles may follow today’s rules, but it is still dragging the network toward a different purpose. This is the nerve BIP-110 touches. It asks whether Bitcoin should keep adapting around data users, or whether users running nodes should draw a line and say: this is not what the base layer is for.
|
 |
|
Of course, that line is not free. A consensus rule is not a personal preference. It is not the same as changing a setting on your own node or choosing a stricter relay policy. If enough people enforce one set of rules while others continue with another, coordination becomes important very quickly. That is why BIP-110 is controversial even among people who dislike inscriptions, token games and the general habit of smuggling shitcoin behavior into Bitcoin while pretending it is innovation.
But the controversy cuts both ways. Calling a consensus change serious doesn't make the underlying concern unserious. BIP-110 exists because many Bitcoiners think Core’s approach accepts too much as inevitable. They hear the argument that miners will mine what pays, and they ask why miner revenue should be allowed to define Bitcoin’s purpose. They see the move towards larger data relay and worry that Bitcoin is being nudged, slowly and politely, into providing permanent infrastructure for use cases that make the monetary network heavier without making it better money.
|
 |
|
The BIP-110 case is not simply “stop the JPEGs”. The deeper fear is not that one inscription breaks Bitcoin. It is that, over time, non-monetary data makes Bitcoin heavier for reasons that do not make it better money. Bitcoin is strong because ordinary users can run nodes, verify the rules and keep the network decentralized from the ground up. If node operation becomes more expensive, more annoying or more specialized, fewer plebs will do it, and Bitcoin becomes easier to centralize around the people and companies still willing to carry the load.
BIP-110 is an attempt to interrupt that drift.
|
The Risk of Drawing the Line |
|
None of this means BIP-110 is an easy answer. You can believe Core v30 made a bad policy decision and simultaneously believe escalating the dispute into BIP-110’s consensus mechanism is the wrong remedy. That is the uncomfortable middle ground in this debate, and it deserves more respect than it usually gets online.
That creates its own risks. If miners, node operators, exchanges, wallets and other infrastructure providers are not sufficiently aligned around activation, the dispute can move beyond unwanted data in blocks and become a disagreement over which blocks the ecosystem should treat as valid Bitcoin.
|
 |
|
There is also the problem of bluntness. BIP-110 may disrupt today’s common inscription patterns and larger OP_RETURN use, but determined data users may still search for workarounds. That doesn’t make the proposal pointless; it simply means nobody should pretend one soft fork can delete every possible abuse of blockspace. Bitcoin needs scripts, signatures and technical structure because those things help secure and move money. That is very different from treating the base layer as open real estate for token schemes, shitcoin collectibles and permanent file storage.
That is why the slogans fail. “Fees decide” is too lazy, because miner revenue doesn’t answer every cost imposed on the network. “Ban the spam” is too easy, because consensus rules are serious tools and serious tools can cut more than their intended target. Existing UTXOs are exempt, only new transactions after activation are affected. The real trade-off is this: tolerate the drift, or risk the boundary. BIP-110 may be blunt, imperfect and uncomfortable. But the fact that a treatment is aggressive doesn’t prove the disease is imaginary.
|
|
Learn More About the BIP-110 Debate |
|
This debate deserves more than another round of shouting online, and that is exactly why we are going deeper in our upcoming podcast.
Our own technical experts, Bert and Kyle, will walk through the strongest arguments on both sides of the BIP-110 debate, explain where the real trade-offs are, and help you understand what may actually matter without needing to live inside a developer mailing list. The goal is not to add more noise to an already noisy argument, but to make the crux of the debate clear: what Core changed, what BIP-110 is trying to do, why reasonable Bitcoiners disagree, and what the possible consequences may be.
|
 |
|
It is also a great chance for you to get to know Bert and Kyle, two of the technical experts behind The Bitcoin Way. These are the people helping clients think through the technical details that most users never see, but still depend on when it comes to running a serious Bitcoin setup.
You can watch the full discussion here: BIP 110 Explained: Bitcoin's Biggest Battle. If you don’t want to miss the episode, subscribe to our YouTube channel and turn notifications on. And if you are already a client, keep an eye on your inbox. And if you are already a client, keep an eye on your inbox. We will be sending practical information and guidance to help you understand what BIP-110 could mean for your own setup, so you can make an informed decision as activation approaches.
|
 |
|
| Become a Client |
|
PS: here are some cool resources to checkout:
🎤 Tony's BTC Prague 2026 Keynote
💬 Bitcoin Banter: This Week’s Top Conversation
🎙️ New Drop from The Bitcoin Way Podcast
🎧 Book Tony for Speaking or Interviews
🌴 Panama - The Plan B Paradise
🧭 Plan B Survey
🧠 How Secure is Your Bitcoin Quiz |
|
|
|
|
|
|
Staying Safe in Bitcoin |
|
If you want to understand the most common forms of FUD, manipulation, and scam tactics used to separate people from their Bitcoin, we strongly recommend the resource below. It distills what we have observed over the years into 11 in-depth articles and continues to grow.
If you are serious about protecting your Bitcoin, this is one of the best places to start. |
|
|
|
|
|
|
|
Remember: |
- The Bitcoin Way will never ask for sensitive information, private keys, or seed words.
- Never enter your seed words on any website.
- Stay alert for phishing attempts, scams, and social engineering attacks.
- Watch for impersonators pretending to be us or any Bitcoin-related service you use.
- Your Bitcoin is yours. No one else should ever have access to it.
- In moments of urgency or panic, slow down. 99% of the time, it is a scam.
|
|
|
|
|
Disclaimer: Please note, The Bitcoin Way does not provide financial, legal, or tax advice. This email is for educational purposes only and is intended to share insights into the technical and security aspects of Bitcoin. Always consult a qualified professional for advice specific to your situation. |
|
|
|
|
|
|