BIP 110 Neutralizes Bitcoin’s Biggest Legal Attack Vector
Arbitrary data on the blockchain creates untested legal exposure for every node operator on the network. BIP 110 is the protocol-level fix that shrinks it.
Every full node on the Bitcoin network downloads the entire blockchain. Archival nodes, the default configuration, store and serve all of it. Even pruned nodes must download and validate every block during initial sync before discarding old data. Either way, every node operator processes content embedded by third parties that they didn’t choose, can’t control, and in the case of archival nodes, cannot remove.
Some of that content is illegal. It has been documented in peer-reviewed research since 2018. And in October 2025, Bitcoin Core v30 expanded the default OP_RETURN relay capacity by over 1,000x, making it significantly easier to embed large contiguous data through the public mempool without requiring direct miner submission or non-standard software.
No court anywhere has tested whether running a node constitutes “possession” or “distribution” of embedded illegal content. That untested question is an attack vector. Not a theoretical one. A practical one that any motivated government actor could exploit to shrink the node set and undermine Bitcoin’s decentralization from the inside.
BIP 110 shrinks that attack surface at the protocol level. By temporarily restricting the data-embedding vectors that create the most exposure, it turns Bitcoin’s protocol design itself into a stronger legal defense for the people who enforce its rules.
The intellectual case: attack surface minimalism
The principle behind BIP 110 isn’t new. It’s the same logic that has guided Bitcoin’s design from the beginning: minimize the attack surface.
Nick Szabo articulated this most clearly across two decades of writing. His 2001 essay, “Trusted Third Parties Are Security Holes,” argued that every invocation of a trusted third party in a security protocol introduces a vulnerability that must be accounted for. The prescription: eliminate vulnerabilities through protocol design. His 2017 essay, “Money, Blockchains, and Social Scalability,” extended this to Bitcoin directly, framing trust as vulnerability: “we are fully trusting, in other words we are fully vulnerable to, the computer, or more specifically the people who have access to that computer.” Bitcoin’s apparent inefficiency is its greatest feature: by doing fewer things, the protocol creates fewer arguments, fewer dependencies, and fewer attack surfaces. In 2018, he distilled it into a maxim: “Bitcoin’s smaller argument surface increases its social scalability.” Protocol minimalism is the security model.
In 2025, Szabo returned to public discourse after five years of silence to apply this framework directly to arbitrary on-chain data. He identified two categories of legal risk for cryptocurrencies: financial regulation, which the industry has largely managed, and arbitrary data, which he called “far more dangerous.” He noted that protocols making on-chain data “easily renderable” as images and files create an exposure unlike anything else on the internet, because node operators cannot remove content without breaking Bitcoin’s core function.
The framework is straightforward. Every byte of arbitrary data capacity added to the protocol is a byte of legal exposure distributed to every node operator. When Bitcoin was limited to small, financial-sized data fields, the attack surface was minimal. When it expanded to accommodate 4 MB inscriptions and 100 KB OP_RETURN outputs, the legal character of what node operators store changed fundamentally.
Documented illegal content: the empirical baseline
The legal risk is grounded in documented fact, not speculation.
In 2018, Roman Matzutt and colleagues at RWTH Aachen University published a quantitative analysis of arbitrary content on the Bitcoin blockchain through August 2017. They found over 1,600 files embedded in transactions. Among them: at least eight files with sexual content, including two containing links to 274 child abuse websites (142 pointing to Tor hidden services), and one image claimed in forums to depict a minor.
Their conclusion was direct: because all blockchain data is downloaded and permanently stored by participants, those participants become liable for objectionable content added by others. No court had ruled on the question, but the researchers found that the laws of Germany, the UK, and the United States all suggest criminal liability could attach.
That was before Ordinals. Before over 80 million inscriptions. Before 4 MB of arbitrary data per block became routine. Before someone inscribed shock imagery onto the chain within days of the protocol launching. Before Core v30 widened the OP_RETURN default from 83 bytes to 100,000 bytes.
The content is there. It’s growing. It cannot be removed. Every full node stores and propagates it.
What Core v30 actually changed
Bitcoin Core v30, released in October 2025, included PR #32406 (merged in June 2025), which increased the default -datacarriersize from 83 bytes to 100,000 bytes and standardized multiple OP_RETURN outputs per transaction. Gloria Zhao’s merge rationale identified a legitimate mismatch: OP_RETURN outputs are prunable and don’t bloat the UTXO set, yet they were more restricted than genuinely harmful alternatives like fake unspendable outputs that pollute the UTXO set permanently. Protocols like the Citrea sidechain bridge were already using unspendable Taproot outputs to circumvent the 83-byte cap.
The technical logic is defensible in isolation. But it ignores the second-order consequence: the reference implementation that most of the network runs now defaults to accepting and relaying over a thousand times more arbitrary data per transaction. The practical barrier to embedding large, contiguous, renderable content on-chain dropped dramatically. Before Core v30, file storage on Bitcoin had to pass through two filters: every node’s mempool relay policy, and the terms of service of whichever mining pool would include the transaction (typically Marathon’s Slipstream service). Core v30 removed the first filter by default. The second was already porous. The result: Bitcoin now has effectively zero gatekeeping for arbitrary file storage. The practical cost of anonymously embedding illegal content on-chain dropped from six figures (requiring you to mine your own block) to a few hundred dollars in transaction fees routed through the public mempool.
The community response reflected the severity. The pull request drew overwhelmingly negative reactions on GitHub before emoji reactions were locked. Luke Dashjr called the changes “malicious code.” Bitcoin Knots adoption surged from roughly 3% to over 21% of network nodes. Gloria Zhao deleted her X account in May 2025 amid sustained personal attacks, even before the PR was merged the following month. Jimmy Song called the change something that “is going to age like a bad tattoo.”
Supporters, including Jameson Lopp and Alex Thorn, argued the caps were already being bypassed through direct miner submission via services like MARA Slipstream, and that restrictive relay rules only created centralization pressure by pushing large players to bypass the public mempool. That argument has merit on its own terms, but it sidesteps the liability question entirely. The fact that data was already getting on-chain doesn’t reduce the legal exposure of making it easier.
The untested legal question
No court anywhere has ruled on whether running a Bitcoin full node constitutes “possession” or “distribution” of illegal content embedded in the blockchain. The question is completely open.
Under U.S. federal law, CSAM offenses under 18 U.S.C. sections 2252 and 2252A require “knowing” possession. The strongest precedent for node operators is United States v. Kuchinski (9th Cir., 2006), which held that a defendant who didn’t know about, didn’t access, and lacked the sophistication to understand cached files on his computer did not “knowingly possess” them. The reasoning maps onto Bitcoin nodes: the software downloads the entire blockchain through an automated process without the operator selecting, viewing, or controlling embedded non-financial data.
Jerry Brito of Coin Center has reinforced the encoding defense: blockchain data appears as hex strings requiring active technical effort to decode into viewable content. It’s analogous to holding a newspaper responsible for a steganographic message imperceptibly embedded in a published photograph. That defense is eroding. Extracting an inscription from the blockchain is now a single command line, and in 2026 any LLM can generate the extraction script in seconds from a sample transaction. The “active technical effort” barrier that the encoding defense relies on is collapsing toward zero.
There is a deeper problem. As Szabo has noted, “knowing” possession is not a fixed state. A node operator who was genuinely ignorant yesterday can become “willful” today simply by learning that illegal content exists on the blockchain, because they cannot delete it without breaking Bitcoin’s core functionality. Every news article, every court filing, every public discussion documenting CSAM on the blockchain is a step toward establishing the knowledge element for every node operator who reads it. The defense degrades with awareness.
A Protos survey of seven crypto-specialized lawyers in October 2025 found six calling the concerns “overblown.” Rafael Yakobi of The Crypto Lawyers noted that CSAM crimes require knowing possession, receipt, or distribution, and automated relaying typically doesn’t satisfy those elements. Julian Fahrer of Bitcoin Laws stated flatly that no court has ever held that running a node amounts to possessing or distributing illegal material.
One lawyer dissented sharply, arguing that hosting CSAM on a hard drive is a strict liability offense. This characterization is questionable under federal precedent (the Supreme Court has required at least a “reckless disregard” standard for CSAM statutes), but it captures the genuine uncertainty. When competent lawyers disagree on a question with no controlling case law, you are one motivated prosecutor away from a test case that sets precedent for everyone.
The safe harbor that doesn’t exist
When the internet faced analogous problems in the 1990s, Congress passed Section 230, shielding platform operators from liability for user-generated content. It was the legal infrastructure that let the internet scale.
No equivalent exists for blockchain.
Section 230 offers some theoretical coverage. A blockchain could plausibly qualify as an “interactive computer service,” and the Seaver v. Estate of Cazes (2019) ruling found Section 230 protects the Tor Project on that basis. But two problems make this insufficient.
First, Section 230 does not override federal criminal law, including CSAM statutes. It was designed for civil liability. If a federal prosecutor brings a criminal case against a node operator, Section 230 offers nothing. FOSTA-SESTA already demonstrated Congress’s willingness to carve exceptions into 230’s protections.
Second, the Tor analogy breaks for archival nodes. Tor relays route transient traffic. They don’t permanently store anything. A default-configuration Bitcoin full node downloads and stores the entire blockchain indefinitely. The legal distinction between conduit and archive matters, and archival Bitcoin nodes function as both. Pruned nodes are closer to the Tor relay model, since they discard old block data after validation, but they still download and process everything during sync, and the legal treatment of that transient exposure remains untested.
The EFF maintains running a Tor relay is legal under U.S. law. DMCA section 512(a) conduit safe harbor protections apply to automated routing. But those protections were designed for transient data, not permanent storage.
Academic scholarship has mapped this gap in detail. A 2023 Marquette Law Review paper argued blockchain occupies a position analogous to the internet in the mid-1990s, before safe harbors existed. European legal scholarship on intermediary liability has found that notice-and-takedown systems cannot function in a blockchain context due to immutability. A 2018 paper in the University of Illinois Law Review warned that DLT projects may be found by courts to constitute joint ventures with liability distributed across all operators.
There is no blockchain-specific safe harbor in any jurisdiction. Node operators exist in a legal vacuum that grows more precarious as the volume and renderability of on-chain data increases.
Why this is existential, not merely inconvenient
Consensus in Bitcoin is the longest valid chain. Miners compete to extend the chain through proof-of-work. Full nodes enforce what “valid” means. Hashrate decides between competing valid chains. Nodes decide what counts as valid in the first place. If 100% of the world’s hashrate produced a block violating consensus rules, every full node would reject it. Hashpower cannot force invalid rules onto the economic majority.
This is not theory. It was demonstrated during the SegWit2x episode in 2017, when a coalition of miners and major companies controlling an overwhelming majority of hashrate attempted to push through a rule change. The node-running community rejected it. The effort collapsed. The nodes won. That episode remains the clearest proof that Bitcoin’s ultimate rule enforcement lives in economically significant validating nodes, not in hashpower alone.
This is why Bitcoin remains decentralized despite pockets of mining centralization. The 21 million cap, block validity rules, the entire consensus ruleset: all enforced by the distributed network of full nodes. SPV wallets assume honest majority hashpower. Full validation removes that assumption. That’s the entire point of running one.
Now connect this to the legal exposure.
If full nodes are the layer that enforces Bitcoin’s rules, and running a full node creates potential criminal liability for content the operator didn’t choose to store, then legal risk becomes a mechanism for shrinking the validating node set. You don’t need to ban Bitcoin. You don’t need to attack miners. You just need to make it legally dangerous to run a node and let attrition do the rest.
Fewer nodes means weaker rule enforcement. Weaker rule enforcement means the economic majority that guards Bitcoin’s consensus properties gets smaller, more concentrated, and more vulnerable to pressure. A government that wants to control Bitcoin doesn’t need to outlaw it. It just needs to make running a node carry enough legal risk that ordinary people stop doing it. If the only nodes left are operated by large, identifiable entities in regulated jurisdictions, Bitcoin’s governance model collapses into something resembling the financial system it was designed to replace.
This is precisely the kind of attack vector that Bitcoin’s design philosophy exists to prevent. Every trust assumption is a vulnerability. Every legal ambiguity is an attack surface. Every byte of arbitrary data on the blockchain is a byte of ammunition for anyone who wants to use the legal system to undermine the one layer of Bitcoin that actually enforces its rules.
BIP 110 shrinks the vectors
BIP 110 is a temporary consensus-level soft fork that would restrict Bitcoin’s ability to carry arbitrary data for one year (52,416 blocks). Unlike Core v30’s relay policy (which individual nodes can override), BIP 110 operates at consensus: blocks violating its rules would be rejected as invalid by every enforcing node.
Its seven restrictions directly target the data-embedding vectors that create legal exposure. The OP_IF prohibition in Tapscript blocks the Ordinals inscription encoding method. The 256-byte limit on data pushes prevents large data chunks anywhere in scripts or witness data. The 83-byte OP_RETURN cap reverses Core v30’s expansion. Additional rules close the Taproot annex, deep Taptrees, and other secondary vectors.
BIP 110 does not eliminate all arbitrary data embedding. Small fragments can still be scattered across transactions, and content already on-chain remains. What it does is remove the most efficient methods for embedding large, contiguous, renderable files — the category that creates the most acute legal exposure.
The legal effect matters as much as the technical one. If the protocol limits embedded data to 83-byte fragments, the “knowing possession” defense becomes overwhelming. No prosecutor is going to argue with a straight face that an 83-byte hex string constitutes possession of illegal content. The protocol design itself becomes the legal defense.
Because it auto-expires, BIP 110 functions as a circuit breaker. It gives the community, the legal system, and the industry time to develop a proper long-term framework without permanently altering consensus rules. If the restrictions cause more harm than good, they disappear on their own. No vote required.
Adoption has been growing steadily, from under 1% in January to nearly 8% of nodes (about 1,920 of approximately 25,200) signaling support as of late February 2026. That needs to keep growing. The people bearing the legal exposure should be the ones driving this conversation.
The bottom line
Protocol design is liability design. Every byte of arbitrary data capacity added to Bitcoin is a byte of legal exposure distributed to every node operator on the network. When the protocol was limited to small, financial-sized data fields, the attack surface was minimal. When it expanded to accommodate 4 MB inscriptions and 100 KB OP_RETURN outputs, it changed the legal character of what node operators store and serve.
The content is already on the chain. The legal question is untested. No safe harbor exists. The reference implementation just made the problem dramatically worse. And the people who bear the consequences, the node operators who enforce Bitcoin’s rules and keep it decentralized, had no meaningful say in any of it.
BIP 110 is the most concrete response available. Run a node. Signal support. Talk to your mining pool. The people with financial incentives to keep the data spigot open are already organized. The people bearing the legal risk need to be.
For a broader breakdown of what BIP 110 does and the most common objections, see Bitcoin Has a Squatter Problem.
Works cited
Szabo, Nick. “Trusted Third Parties Are Security Holes” (2001). nakamotoinstitute.org/library/trusted-third-parties/
Szabo, Nick. “Money, Blockchains, and Social Scalability.” Unenumerated, Feb. 2017. unenumerated.blogspot.com/2017/02/money-blockchains-and-social-scalability.html
Szabo, Nick. X posts on legal attack surface, Nov. 16-17, 2025; Feb. 22, 2026.
Matzutt et al. “A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin.” Financial Cryptography and Data Security (FC 2018), Springer LNCS.
PR #32406: “policy: uncap datacarrier by default.” bitcoin/bitcoin, GitHub. Merged June 2025. github.com/bitcoin/bitcoin/pull/32406
“Lawyers call Bitcoin Core v30 CSAM concerns ‘overblown.’” Protos, Oct. 3, 2025.
United States v. Kuchinski, 469 F.3d 853 (9th Cir. 2006).
Seaver v. Estate of Cazes, No. 18-00712 (D. Utah 2019).
18 U.S.C. §§ 2252, 2252A; 47 U.S.C. § 230; 17 U.S.C. § 512(a).
Cyphert & Perl, “Blockchain Safe Harbor?” 107 Marq. L. Rev. 145 (2023).
Zetzsche, Buckley & Arner, “The Distributed Liability of Distributed Ledgers.” 2018 U. Ill. L. Rev. 1361.
Ohm, Dathon. “BIP 110: Reduced Data Temporary Softfork.” Assigned Dec. 3, 2025. bips.dev/110/
Brito, Jerry. “Could Your Bitcoin Node Be Illegal?” Coin Center, March 2018.