Bitcoin is built on an uncomfortable truth: adversaries exist.
That is why we have proof of work. That is why nodes validate. That is why wallets check addresses. That is why signatures are verified, blocks are rejected, and invalid money is ignored.
Nobody says, “I do not think fake signatures will be a problem.”
Nobody says, “I do not think people will mistype addresses.”
Nobody says, “I do not think miners will ever try anything dishonest.”
Bitcoin does not work because everyone is trusted.
Bitcoin works because the system is designed as if someone, somewhere, will eventually try the worst thing the rules allow.
That is the mindset needed for the data carrier debate.
Bitcoin addresses have checksums.
Most of the time, those checksums appear to do nothing. You paste an address, the wallet accepts it, and the transaction goes through.
But the checksum is not useless. It is quietly working every time. It is there for the rare case where one character is missing, swapped, mistyped, corrupted, or maliciously altered.
The point is not that mistakes happen every minute.
The point is that one mistake can be catastrophic.
So Bitcoin adds a cheap safeguard.
That is normal security engineering.
The same logic applies to arbitrary plaintext data in transactions.
A common response is:
I really do not think this is a problem.
That may be a sincere intuition, but it is not a threat model.
In security, the question is not:
Do we think everyone will behave?
The question is:
What happens if Mallory exploits the path deliberately?
If a path is cheap, scalable, harmful, and obvious, an adversarial system should assume someone will eventually use it.
Bitcoin is not a polite dinner party. It is a global adversarial network securing trillions of dollars of value.
“Nothing burger” is not analysis. It is dismissal.
A Bitcoin full node is not just a passive observer.
A normal full node downloads, validates, stores, and relays Bitcoin data. That is the point of the network. Nodes help other nodes receive blocks and transactions. Archival nodes may serve old blocks. Explorers, APIs, wallets, indexers, and hosted services often make that data easier to search, decode, and display.
So if an attacker places abusive plaintext data in a standard transaction field, the issue is not abstract.
The network can be made to carry it.
That does not mean ordinary node runners are bad people. It does not mean they intended anything. It does not mean they are guilty of a crime.
It means the protocol surface has been abused.
That is exactly what threat modeling is for.
Some data is not merely unwanted. Some data is illegal to possess, distribute, publish, or make available in many jurisdictions.
Examples include child sexual abuse material, certain terrorist material, classified information, stolen personal data, malware, copyrighted works at scale, or export-controlled technical data.
The exact law depends on the country, and most serious criminal statutes require knowledge or intent. That distinction matters.
But Bitcoin policy should not rely on ordinary users arguing fine points of criminal intent after the fact.
A good design avoids putting them in the blast radius in the first place.
The point is not:
Every node operator is knowingly distributing illegal material.
The point is:
Why keep an obvious, cheap, plaintext path open when an adversary can use it to create legal, social, reputational, and regulatory pressure against Bitcoin?
That is the attack.
“But data can be hidden elsewhere”
Yes. It can.
Arbitrary data can be hidden in other parts of transactions. It can be disguised, split up, encoded, placed in scripts, or carried through more obscure channels.
That argument proves only one thing:
You cannot reduce arbitrary data to zero.
It does not prove that Bitcoin should enlarge the easiest, cleanest, most indexable plaintext path.
People can smuggle contraband in luggage. Airports still restrict obvious cargo channels.
Locks can be picked. We still lock doors.
Checksums do not stop every possible mistake or attack. We still use them.
Security engineering is not about perfection. It is about reducing cheap, scalable, catastrophic failure paths.
Hidden data and plaintext data are not the same threat.
Hidden data is covert. It is harder to interpret, harder to index, harder to render, and harder to make immediately legible to normal software.
Plaintext data carrier is different.
It is explicit. It is standardized. It is easy to parse. It is easy to index. It is easy for explorers, APIs, wallets, and dashboards to expose. If it contains a MIME type, a data URI, or recognizable file structure, the payload becomes self-describing.
That changes the risk.
Once abusive data is publicly identified, the “unknowing” argument gets weaker for services that continue to store, relay, index, display, or serve it.
And that is just the one-off case.
The real adversarial case is flooding.
Imagine an attacker does not place one abusive payload into the data carrier.
Imagine they place many.
Again and again.
Loudly.
In plaintext.
In a way that is easy for journalists, regulators, activists, or hostile governments to point at.
The goal is not only to store bad data.
The goal is to force Bitcoin infrastructure into a dilemma:
- Relay and expose the data, then be accused of distributing it.
- Filter it after the fact, then admit the policy surface was dangerous.
- Centralize around services that can censor or sanitize it.
- Push ordinary users away from running nodes.
That is a social attack on Bitcoin through a technical opening.
It attacks the willingness of normal people to participate in the network.
The answer does not need to be perfect to be worthwhile.
If abusive payloads cannot be stopped everywhere, at least stop making the plaintext path larger.
If covert channels remain, at least close the overt channel.
If a determined attacker can still try something obscure and expensive, at least do not give them a cheap public billboard.
This is the modest claim:
Bitcoin should not provide a large default plaintext data carrier for arbitrary content when that path can be abused against node operators and the network itself.
That is not panic.
That is normal adversarial thinking.
Ask three questions:
- Is the abuse path cheap?
- Is it scalable?
- Is the downside catastrophic for ordinary users or Bitcoin’s reputation?
If the answer is yes, then “I do not think it will happen” is not enough.
Bitcoin does not survive by assuming attackers will be polite.
Bitcoin survives by closing the loopholes before Mallory uses them.
The data carrier issue is not about calling opponents names. It is not about claiming every node runner is guilty. It is not about pretending all arbitrary data can be eliminated forever.
It is about a basic security principle:
Do not make the easiest harmful path bigger.
Checksums are worth having even though errors are rare.
Validation is worth having even though most blocks are valid.
Relay policy is worth having even though most users are honest.
And limiting plaintext arbitrary data is worth doing even though covert channels remain.
Because Bitcoin is not designed for the world we wish existed.
It is designed for the world where adversaries exist.