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

Posted by MrHash

Jul 3, 2026/17:03 UTC

The SegData proposal is designed to modify the way resources are controlled within blockchain networks by ensuring data carriers are accountable for the resources they use. This model prevents the possibility of carrying data without incurring any costs, addressing a critical concern that free data carriage could disrupt the system's economic balance. The proposal distinguishes itself from existing overlay designs like OP_RETURN+IPFS, RGB, and OpenTimestamps, which partially redirect traffic off-chain but do not fundamentally alter the economic dynamics as SegData intends.

Unlike coin burns, which permanently remove coins from circulation without compensation and have seen poor market adoption, SegData introduces a mechanism where fees act as a transferable resource, thereby not diminishing the overall economic pool. This fee-based structure ensures that even with zero participation, SegData will still provide a priced, bounded, and committed record, maintaining its utility and relevance. In scenarios of low participation, while SegData might resemble an overlay in function, it remains distinct in its foundational approach and implications.

The retention of SegData by default among Bitcoin node operators illustrates the community's tendency towards data preservation rather than pruning. This reflects a broader preference rooted more in ideological values rather than mere resource constraints. SegData empowers node operators by delegating the decision of data pruning directly to them, considered the most legitimate locus for such decisions. The argument extends to potential risks associated with universal data pruning due to resource limits, which could jeopardize block availability essential for network synchronization. Thus, if pruning becomes necessary, it must be strategically priced to mitigate the risk of undermining the currency's utility or leading to centralization through uneven policy enforcement. To address these economic considerations, implementing a cap on region sizes within SegData might be a viable solution to effectively reduce block sizes for nodes opting out, enhancing overall network efficiency without compromising on decentralized integrity.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback