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

The latest proposal in the BIPs repository introduces a method to make data fields optional at each hierarchical level while maintaining the same consensus validation mechanisms, thereby addressing concerns about reorganization risks highlighted by AJ Towns. This approach involves nodes checking only a commitment and its declared size against the block weight limit, relegating all other considerations to policy matters. This method would be enacted as a soft fork, simplifying implementation since it does not alter existing consensus rules. Currently, it is possible to commit to arbitrary data hashes; however, such data still consumes block space without necessitating preservation or distribution, leading most nodes to disregard it, which results in unreliable availability.

Further, this proposal suggests that use cases requiring data permanence would likely continue utilizing conventional methods like normal witness or OP_RETURN data, indicating a selective preference for this new optional data feature among users. The implication of adding such functionality is an increase in protocol complexity with minimal incentive for adoption, as most nodes are expected to disable this feature due to the lack of compelling reasons to utilize it extensively.

Moreover, there appears to be a consensus among developers, including endorsements from notable community members such as @garlonicon, regarding the practical challenges and limited appeal of storing large arbitrary data blobs using this proposed SegData method. Concerns center around whether enough nodes will opt to host and serve such data, considering the additional complexities and the nature of the soft fork required for implementation. This highlights a broader skepticism about the feasibility and desirability of this feature within the network, reflecting a cautious stance on its broad implementation.