Now here's a BIP draft to add room for data in blocks. But before you get your panties all in a bundle about how it's a horrible idea (which it may be), give it a little thought, because it's kinda the same reasoning that gave us data in OP_RETURNs in the first place.

I’ve drafted companion BIPs for Segregated Data (SegData), a soft-fork block region for arbitrary data (data without an intent to transfer value). SegData entries are committed in-block through a separate Merkle root and validated at the tip by every node. Beyond the standard retention window a node may prune them individually or in bulk, so the storage cost falls on the operators who choose to keep the data rather than on everyone.

This is not an effort to promote data carriage, rather to give it a designed structural home. OP_RETURN mitigated UTXO bloat by drawing data out of fake outputs, but its bytes are still synced in full and stored permanently by every node. SegData offers to carry the same data in a prunable region at the witness discount, so a carrier has sensible reasons to migrate. The OP_RETURN precedent shows the approach works in principle. Altering the existing vectors is deliberately out of scope.

I think the goal is to make it so that when data is stored in blocks, it is the least burdensome to node operators who do not care about the data. However, it achieves this via a construction that mostly saves on disk space, which is probably not the most expensive part of the process (node runners still need to download the data and process it at least once).

Edit: I may be wrong about that last bit. Here is Mr Hash's response to Antoine Ponsoit on delving:

I still suspect a proposal like this is not the right way to mitigate people trying to stuff data in blocks, but then again I may be a free-market maximalist who's willing to let miner fees and blocksize limits dictate it all.

Here's a link to the BIP draft

And here's a link to a second BIP for p2p relay.

And here's an announcement post on X:

source