nonoise₿itcoin

With Bitcoin Core v30 removing the 80-byte OP_RETURN relay cap, transactions with very large OP_RETURN payloads can now propagate by default, up to block weight limits.

In a stress-test context, I’d like to understand how Core behaves under the following extreme but practical scenarios:

1. All-OP_RETURN blocks: If miners fill entire 4 MB blocks with nothing but large OP_RETURN outputs, what are the validation and propagation consequences?
2. Mempool flooding: What happens if the network is flooded with thousands of very large OP_RETURN transactions that linger unconfirmed? How does eviction perform against “fewer but heavier” junk txs?
3. Propagation asymmetry: Could sustained megabyte-heavy blocks widen propagation gaps between high-bandwidth and low-bandwidth miners, increasing orphan risk and centralization pressure?
4. Storage growth: Sustained 4 MB junk blocks would grow the chain by ~576 MB/day (~210 GB/year). How well does Core’s blockfile and database design handle such growth, especially for pruned nodes?
5. Fee market impact: If OP_RETURN demand competes directly with monetary transactions, has fee estimation been stress-tested for non-financial blockspace usage?

Even if UTXO growth is unaffected (since OP_RETURN outputs are provably unspendable), could these scenarios introduce new kinds of network bloat or centralization pressure under the new default policy?

In short, blocks filled with large OP_RETURN transactions are smaller and faster to validate than normal monetary transactions—smaller because OP_RETURN outputs do not benefit from the witness discount, and faster to validate because there are fewer signatures to check.

Going point by point:

1. Since OP_RETURN doesn't use the witness discount, blocks containing only large OP_RETURN outputs cannot be larger than ~1 MB. Lifting the default limit only benefits propagation of such blocks, as nodes will already have those transactions stored and validated (cf. compact block relay).
2. Since the maximum standard transaction weight is not lifted, transactions with large OP_RETURN outputs can only be up to ~100 kB, as opposed to up to ~400 kB for transactions with predominantly witness data. Lifting the OP_RETURN limit does not change anything.
3. Orphan risk is strictly reduced by removing unnecessary standardness rules, as it speeds up the propagation of blocks with previously non-standard transactions (again, cf. compact block relay).
4. Again, blocks with large OP_RETURN outputs are smaller than blocks expected under strictly monetary use, and much smaller than the worst case of 4 MB blocks.
5. Fee estimation works exactly the same for monetary and non-monetary transactions, and we've seen both types of transactions create periods of high fees in the past.

1. All-OP_RETURN blocks: If miners fill entire 4 MB blocks with nothing but large OP_RETURN outputs, what are the validation and propagation consequences?

They cannot. OP_RETURNs exist in transaction outputs, which are not subject to the witness discount. The largest consensus-valid OP_RETURN output is slightly under 1 million bytes, significantly smaller than what is possible with completely ordinary segwit transactions. They are are also far simpler to validate; it's transaction inputs that are expensive in terms of computation and I/O terms.

Even ignoring that, relay policy is still restricted to 100 kvB transactions. A miner can of course exceed that, but that was already the case, and their ability to do so is unaffected by the (default) policy changes in Bitcoin Core v30.

2. Mempool flooding: What happens if the network is flooded with thousands of very large OP_RETURN transactions that linger unconfirmed? How does eviction perform against “fewer but heavier” junk txs?

Fewer larger transactions is far preferable in this regard than many small transactions.

3. Propagation asymmetry: Could sustained megabyte-heavy blocks widen propagation gaps between high-bandwidth and low-bandwidth miners, increasing orphan risk and centralization pressure?

That is why the block weight limit exists. Blocks could be filled to 1 MvB (and up to 4 MB serialized size) regardless of policy, and frequently have been. If anything, including large OP_RETURNs reduces the impact here, as they are not subject to the witness discount 4x factor, so their inclusion displaces more witness bytes than their own serialized size.

4. Storage growth: Sustained 4 MB junk blocks would grow the chain by ~576 MB/day (~210 GB/year). How well does Core’s blockfile and database design handle such growth, especially for pruned nodes?

Sustained 4 MB junk blocks are already possible. OP_RETURN outputs reduce the disk growth space, by not being subject to discount.

5. Fee market impact: If OP_RETURN demand competes directly with monetary transactions, has fee estimation been stress-tested for non-financial blockspace usage?

I don't see how fee estimation would be affected by, or is in any way related to, the user's intent for transactions.