bitcoin-dev

Adding New BIP Editors

Adding New BIP Editors

Original Postby Anthony Towns

Posted on: April 4, 2024 05:00 UTC

The email from Niklas Goegge for BINANA delves into the intricacies of handling Bitcoin Improvement Proposals (BIPs) and Bitcoin Inquisition New Asset Announcements (BINANAs), focusing on the criteria for acceptance and the classification of proposals based on their relevance to Bitcoin's monetary properties.

Goegge argues that proposals should only be rejected if they are unrelated to Bitcoin, rather than being dismissed as irrelevant or impractical. This approach is aimed at streamlining the decision-making process by avoiding debates over a proposal’s merit in favor of assessing its relevance to Bitcoin.

An example provided discusses whether adding script opcodes specifically designed to facilitate the movement of BTC to and from sidechains—such as Liquid or WBTC on Ethereum, which could then be used as collateral in trading other tokens—should be considered as supporting the Bitcoin currency. The conversation extends to differentiating between features that support asset trading and those that inherently support Bitcoin as a currency, highlighting the complexity in classifying proposals that might not directly impact Bitcoin's consensus but still influence its ecosystem.

Moreover, the email touches on the value of having a "Discussion" header in BINANA documents, pointing out its usefulness for tracing the development of proposals and gathering feedback, despite seeing little need for a dedicated discussion area within the BINANA/BIP repository itself. The importance of documenting consensus change activation, as permitted in BIP 90, is acknowledged, suggesting that how a standard transitions from "Proposed" to "Active" status is crucial for understanding community acceptance and implementation readiness.

Goegge outlines the lifecycle of a proposal, categorizing it into stages such as Draft, Proposed, Active, and Withdrawn, each reflecting the proposal’s maturity and adoption status. This lifecycle not only aids in managing expectations around a proposal's stability and deployment but also clarifies the conditions under which a proposal might advance or recede in status. Additionally, the email reevaluates existing classifications like Deferred, Rejected/Obsolete, Final, and Replaced, proposing simplifications to streamline the process.

The discussion extends to specific BIP examples, including BIP 148 and BIP 91, illustrating how the designation of "Active" can apply even in the absence of unanimous community consensus, so long as there is software actively implementing the standards. This perspective underscores the pragmatic approach to proposal classification, where operational reality trumps theoretical approval.

In conclusion, the email from Niklas Goegge presents a comprehensive view on the management and classification of BIPs and BINANAs, emphasizing a practical, relevance-based approach to proposal evaluation. By focusing on the direct connection to Bitcoin and the operational status of implementations, the proposed system aims to simplify the governance of Bitcoin's evolving technological landscape.