Announcing Bitcoin BOSD: Standardized Withdrawal Output Specification for L2s

In an insightful communication, the intricacies of implementing standardness rules atop a BIP385 raw() output script descriptor were explored, drawing attention to its benefits such as efficient representation, compatibility with diverse software, and the incorporation of a compact checksum alongside local policy considerations. The discourse highlighted an alternative approach to handling transactions that exceed the conventional byte limitations set by Bitcoin Core's standard transaction rules. Specifically, it delves into the challenges posed by OP_RETURN outputs that surpass 83 bytes cumulatively, pointing towards a segment of users who operate under less restrictive transaction rules, potentially including some miners. This scenario underscores the dilemma faced by software users in scenarios where their transactions, due to exceeding the 80 push bytes limit, may not relay to compatible miners, thereby necessitating a workaround.

The discussion proposes a critique of the proposed solution to this issue, which involves creating type 5 transactions or extending numeric ranges for bypassing byte limits—both approaches deemed impractical due to the need for central coordination or the potential rejection based on non-standard transaction sizes. A more viable solution suggested entails eschewing versioning altogether in favor of local verification on raw() descriptors. This adjustment would enable users to modify a single line of code to accept larger data carrier outputs, thus offering a flexible and user-friendly way to accommodate transactions that do not conform to default size restrictions.

Furthermore, the conversation touches upon terminological concerns, specifically the use of the term BOSD which is seen as conflating with the term "output script descriptors," a concept introduced by Bitcoin Core developers in 2018. The recommendation to adopt a more distinct naming convention for the proposal was put forth to avoid confusion and ensure clarity within the developmental community.

For further reference, the original GitHub commit related to this discussion can be viewed here.