- 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 amount of OP_RETURN data in a block 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.
- 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.
- 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.
- 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.
- 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.
