Posted by MrHash
Aug 7, 2026/13:09 UTC
The discussions around the adoption of SegData focus primarily on its feasibility and practical implementation rather than its technical functionality. SegData is designed to align closely with the established BIP-159 standards, which suggest that concerns related to data pruning by type should be considered similarly to pruning by depth, a practice already accepted within the network. The design of SegData ensures that data retention defaults to an archival state, while providing mechanisms for controlling the depth of coverage through various tiers. Moreover, a policy ensures that recent entries are always available, maintaining broad redundancy unless specifically opted out by operators.
Critics of SegData have compared it to an ideal of uniform redundancy, which in reality, does not exist as pruning practices are already in place. The key advantage of implementing SegData lies in its ability to separate block storage from arbitrary data, making such data consensus-irrelevant and independently prunable. This separation grants operators more flexibility, allowing them to manage their resources more efficiently, especially beneficial for nodes with limited resources. This aspect of SegData not only enhances the potential for broader network participation but also strengthens network decentralization, a point that has been underexplored despite its significant implications for incentivizing operator behavior. Such decentralization is crucial as it reduces the operational burden on individual nodes, fostering a more robust and diverse network ecosystem.
Thread Summary (46 replies)
Jun 23 - Aug 7, 2026
47 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback