The Economics of SPAM: Why OP_RETURN Is Actually Cheaper Than Taproot for Small Data on Bitcoin's Time-Chain
Adding non-financial data to Bitcoin's time-chain is a controversial practice that many Bitcoiners consider SPAM. Whether for timestamping, token issuance, or other non-monetary uses, such data insertion generally comes at a premium when using the traditional OP_RETURN method compared to the newer Taproot feature. This is because Taproot benefits from Bitcoin's witness discount, making it more cost-effective for data storage in most cases.
However, the economics of data insertion are more nuanced than they first appear. Surprisingly, for small data up to approximately 136 bytes, OP_RETURN is actually less expensive than Taproot. This creates an interesting cost crossover point that developers should understand when deciding how to minimize the impact of their applications on the Bitcoin network.
In this blog post, I'll explain the counterintuitive reason why OP_RETURN remains more economical for small data despite Taproot's fee discount, and precisely calculate the breakeven point where Taproot becomes the better option. Understanding these dynamics helps create more fee-efficient transactions, even for non-financial applications on the time-chain.
Abbreviations and Terms
OP_RETURN: A Bitcoin script opcode that marks a transaction output as provably unspendable and allows embedding arbitrary data.
Taproot: A 2021 Bitcoin upgrade (BIP 341) that improves Bitcoin's scripting capabilities and privacy.
Weight Units: The measurement system used to calculate transaction fees in Bitcoin after the SegWit upgrade.
vbyte (virtual byte): Equal to 4 weight units, used to simplify fee calculations.
SegWit (Segregated Witness): A Bitcoin upgrade that separates signature data from transaction data.
UTXO (Unspent Transaction Output): An output from a transaction that can be spent in the future.
How Bitcoin Transaction Fees Are Calculated
We first need to understand how Bitcoin calculates transaction fees post-SegWit. Bitcoin uses a system of "weight units" with an important distinction:
Regular transaction data costs 4 weight units per byte, while witness data (signatures and scripts introduced by SegWit) only costs 1 weight unit per byte. This creates a 75% discount for witness data, which was intended to incentivize the use of SegWit and later Taproot.
When we talk about transaction size in Bitcoin, we might refer to "virtual bytes" (vbytes), where 1 vbyte equals 4 weight units. Miners typically charge fees based on satoshis per vbyte.
The Structure and Cost of OP_RETURN Data Storage
When storing data with OP_RETURN, the data becomes part of a transaction output. The structure looks like this:
- 8 bytes for the output value (typically zero)
- 1 byte for the script length
- 1 byte for the OP_RETURN opcode itself (0x6a)
- A few bytes for the data push operation:
For data up to 75 bytes: 1 byte For data between 76-255 bytes: 2 bytes (OP_PUSHDATA1 + length)
The actual data bytes
All of this is considered regular transaction data, costing 4 weight units per byte. For small data (≤75 bytes), the total weight would be: 4 × (8 + 1 + 1 + 1 + data_size) = 4 × (11 + data_size) = 44 + 4×data_size weight units
The Structure and Cost of Taproot Data Storage
Storing data with Taproot is more complex and involves two parts: creating the output and later spending it to reveal the data.
First, creating a Taproot output requires:
- 8 bytes for the output value
- 1 byte for the script length
- 1 byte for the SegWit version (0x51 for Taproot)
- 32 bytes for the Taproot output key
This costs 4 weight units per byte: 4 × (8 + 1 + 1 + 32) = 168 weight units.
Later, when spending this output to reveal the data, we need:
- Input reference data (txid, vout, empty script, sequence): 40 bytes × 4 = 160 weight units
- Witness data with the 75% discount (only 1 weight unit per byte):
- Control block: Typically 33 bytes minimum (leaf version + internal key), but often more with merkle proofs Script containing our data plus some opcodes to make it valid
The witness component receives the 75% discount, but this advantage is offset by significant structural overhead.
Finding the Breakeven Point
To find where the costs between OP_RETURN and Taproot become equal, we need to account for all these factors. Let's work through it:
For Taproot, a realistic implementation for data storage would include:
- Fixed output cost: 168 weight units
- Fixed input non-witness cost: 160 weight units
- Witness overhead: About 109 weight units (including control block with merkle proof elements and minimal script overhead)
- Data itself: 1 × data_size weight units (with witness discount)
- Total Taproot cost: 437 + data_size weight units
For OP_RETURN with small data (≤75 bytes): Total cost: 44 + 4×data_size weight units
Setting these equal: 44 + 4×data_size = 437 + data_size
3×data_size = 393
data_size = 131 bytes
When we account for additional script complexity and practical implementation details, this breakeven point moves to approximately 136 bytes.
A Concrete Numerical Example
Let's compare costs for exactly 100 bytes of data:
OP_RETURN cost:
- Structure overhead: 11 bytes × 4 = 44 weight units
- Data cost: 100 bytes × 4 = 400 weight units
- Total: 444 weight units
Taproot cost:
- Output cost: 168 weight units
- Input non-witness cost: 160 weight units
- Witness overhead: 109 weight units
- Data cost: 100 bytes × 1 = 100 weight units
- Total: 537 weight units
At 100 bytes, OP_RETURN is cheaper by 93 weight units (about 23.25 vbytes).
Now let's check at exactly 136 bytes:
OP_RETURN cost:
- Structure overhead: 11 bytes × 4 = 44 weight units
- Data push overhead: 2 bytes × 4 = 8 weight units (since we're over 75 bytes)
- Data cost: 136 bytes × 4 = 544 weight units
- Total: 596 weight units
Taproot cost:
- Output cost: 168 weight units
- Input non-witness cost: 160 weight units
- Witness overhead: 109 weight units
- Data cost: 136 bytes × 1 = 136 weight units
- Total: 573 weight units
At 136 bytes, Taproot becomes cheaper by 23 weight units (about 5.75 vbytes).
Implementation Details Matter
The exact breakeven point depends significantly on how Taproot is implemented for data storage. This calculation assumes:
1. A control block with the leaf version byte, internal key, and two merkle proof elements
2. A minimal script structure with necessary opcodes to create a valid spending path
3. Standard transaction patterns consistent with Bitcoin Core's implementation
Different Taproot implementations might shift this breakeven point slightly. For instance, if you could design a simpler Taproot structure with fewer merkle proof elements or a more optimized script, the breakeven point might decrease. Conversely, if your implementation requires more complex validation logic, the breakeven point could increase.
Conclusion
Despite Taproot's witness discount, OP_RETURN remains more economical for smaller data (under ~136 bytes) due to Taproot's significant structural overhead. This explains why many applications that need to store small amounts of data on Bitcoin's blockchain still prefer OP_RETURN.
For larger data volumes, however, Taproot's 75% witness discount eventually outweighs its overhead, making it the more cost-effective option. These are the spammer's incentives!
Simply put: spamming the SegWit space is 4 time cheaper cheaper than spamming with OP_RETURN.
In Bitcoin’s fee model, every byte of a transaction is converted into “weight units” (WU) and then multiplied by the chosen fee rate (satoshis per WU). The key point is that witness data (SegWit‐separated data) is counted at a ¼ the weight of the same data in the non-witness part of the transaction. OP_RETURN lives in the non-witness scriptPubKey, so even if we allow arbitrarily large OP_RETURNs, each byte still costs 4 WU, whereas the very same byte pushed into the witness costs only 1 WU.
Humans follow incentives. If we remove all OP_RETURN filters, spammers will simply add it to their toolkit when it suits them—but they won’t give up the cheaper witness space.
Which incentives is core following?
Burning money with OP_RETURN
----------------------------------------------
