[BIP Draft] Segregated Data: a prunable, script-isolated block region for data carriage

The proposed Segregated Data (SegData) introduces a new method for handling arbitrary data within Bitcoin blocks through a soft-fork, focusing on efficient data storage without intending to transfer value. SegData entries are committed in-block via a distinct Merkle root and validated at the tip by every node, allowing for optional pruning past a standard retention window. This design places the burden of storage costs on operators who opt to retain the data, rather than distributing it across the entire network.

SegData is engineered following the structure established by BIP-141, incorporating a coinbase output for commitment over a separate Merkle root. The proposal includes modifications to block serialization and an extension of the weight formula, alongside the introduction of reference outputs which are witness v2, hold no value, are unspendable, and are excluded from the UTXO set. These features ensure that the data remains prunable as consensus does not require reading the entries post-validation, and they cannot trigger any transactions. Additionally, the validation of data is depth-scoped, with full enforcement within the retention window and reduced checks thereafter, ensuring synchronization does not depend on nodes retaining data voluntarily.

Potential adopters of SegData include off-chain data interpreters like indexers for application-layer assets, timestamping services, and attestations, which currently dominate this kind of data carriage. However, data requiring evaluation by script at spend time, such as covenant-style constructs, cannot migrate due to the isolation of scripts from entry contents. The feasibility for other types of data will be determined once an affordable, consensual alternative is available and can be measured effectively.

Several open questions remain regarding the implementation specifics of SegData. These include decisions about sharing or dedicating version and length slots for witness v2, the benefits of committing per-reference entry lengths for transaction weight and fee rate calculations, and the scope boundaries concerning restrictions on existing vectors. Additionally, considerations regarding the granularity of coverage tiers for peer services are crucial to balance between aiding node pairing for data retrieval and protecting privacy against fingerprinting threats.

For more detailed discussions and feedback, interested parties can refer to the draft BIPs provided Consensus BIP and Peer-services BIP.