1/
🧵
Bitcoin’s Data Carrier Controversy: From Bug to Spam
Bitcoin is money. But since the beginning some have tried to use it as a data storage system. To prevent abuse, Bitcoin Core added OP_RETURN in 2014. This allowed small amounts of data to be attached to transactions but capped at 80 bytes. That cap was enforced by a setting called datacarriersize. The purpose was simple... keep Bitcoin lean by letting small proofs exist while stopping spam.
2/
Before OP_RETURN people were already hacking the system by creating fake outputs to carry data. That polluted the UTXO set and increased the load for every node. OP_RETURN was meant to solve this. It let data be included in a way that was provably unspendable so nodes would not have to track it forever. The 80 byte cap was chosen as the balance between utility and protection.
3/
For years this worked. Node operators could even adjust datacarriersize if they wanted to allow more or less data. Most left it at the default 80 bytes. Then came Taproot in late 2021. Taproot was designed to make complex spending conditions and multisig more private and efficient. But it also created a loophole in how data limits were enforced.
4/
With Taproot it became possible to hide large amounts of arbitrary data inside witness fields. By using tricks like OP_FALSE OP_IF developers could embed whole images, texts and even games. These “inscriptions” bypassed the 80 byte OP_RETURN cap because the data was no longer in OP_RETURN at all. It was hidden in witness scripts that had a fee discount.
5/
This was never the intent of Taproot. Witness data was discounted to encourage upgrades like SegWit and to reduce signature malleability. It was not meant to subsidize people storing JPEGs on chain. From a policy standpoint this was abuse. The clean solution would have been to extend datacarriersize so it applied to all data carriers including witness scripts.
6/
Instead Bitcoin Core maintainers went in the opposite direction. In 2022 the definition of datacarriersize was changed. The wording was narrowed from “maximum size of data in data-carrier transactions” to “relay and mine transactions whose data-carrying raw scriptPubKey is of this size or less.” That meant datacarriersize now only applied to OP_RETURN outputs. Marco Falke merged this change and other maintainers ACKed it.
7/
This semantic change mattered. By limiting the scope only to OP_RETURN, Core effectively declared that witness data abuse was outside of the rule. Spam was legitimized not by fixing the bug but by redefining what counted as a data carrier. This left inscriptions free to spread without being blocked by the existing policy knob.
8/
In 2023 a pull request tried to fix this. It proposed expanding datacarriersize again so it would cover witness data and stop the abuse. This would have restored the original intent: Bitcoin allows small proofs but not arbitrary junk. But the PR was closed by Andrew Chow after Gloria Zhao and others said it was too controversial and lacked consensus. The fix was rejected and the loophole remained open.
9/
Now in 2025 with Bitcoin Core v30 the policy has shifted even further. The 80 byte OP_RETURN cap is removed. Multiple OP_RETURN outputs are allowed in a single transaction. The datacarriersize option is deprecated and its semantics are weakened. A value that once allowed about 92 bytes of data now permits close to 830 bytes. In effect the knob has been turned into a rubber stamp for more data.
10/
This sequence is clear. A loophole in Taproot was exploited to bypass limits. Instead of closing it, Core redefined the rules so it no longer counted as abuse. Proposals to fix it were blocked. Finally the last guardrails were dismantled in v30. The result is more spam in Bitcoin blocks. Junk data is now permitted by default.
11/
Bitcoin was not built to be a storage service. It can anchor proofs or timestamp certificates. But using witness discounts to embed megabytes of images is an attack on the network’s efficiency. Block space is scarce. Spam drives up costs for ordinary users and bloats the chain for every full node.
12/
The bug in Taproot was never fixed. It was renamed and normalized. Bitcoin Core’s policy choices enabled inscriptions to grow and now v30 makes it easier than ever. If Bitcoin is to remain sustainable as money, node operators must enforce their own limits. Otherwise the chain risks being filled with junk.
13/
The answer is protest. Do not accept defaults that enable spam. Run software that respects Bitcoin’s purpose as money. Bitcoin Knots already enforces stricter limits and rejects inscription junk. If Core will not defend the network, node operators must.
Run @BitcoinKnots
