Changes to BIP-360 - Pay to Quantum Resistant Hash (P2QRH)

The discussion revolves around the unconventional use of SegWit (Segregated Witness) versions in Bitcoin development, specifically addressing a proposal to utilize SegWit versions not as sequential identifiers but as markers for different types of transaction outputs. The idea here is to assign distinct SegWit versions to denote specific output types rather than following a numerical order. For example, SegWit version 3 could be assigned to a type of address starting with "bc1(r)", indicating a particular feature or function, such as P2QRH. Subsequently, another output type might use SegWit version 2, marked by "bc1(z)" to signify a zero-knowledge proof output. This approach aims to leverage SegWit versions as flags to signal the output type within an address, moving away from their conventional incremental usage.

The motivation behind this proposal is twofold. Firstly, it seeks to reduce confusion and user error by simplifying the identification of output types through clear, designated SegWit versions. This method is believed to enhance usability for both developers and users by making the system more intuitive. Secondly, the discussion invites community feedback on the advisability of adopting such a method over the traditional sequential numbering of SegWit versions. The proponent of this idea emphasizes the importance of community consensus, expressing a willingness to prioritize the introduction of P2QRH over the proposed flagging mechanism if the latter lacks sufficient support.

Criticism of the proposed method falls into three main categories. Some argue that there may be overlooked technical reasons necessitating incremental SegWit versions, which the proposal fails to account for. Others believe that the complexity introduced by this method outweighs its usability benefits, making it unsuitable for bitcoin-core development. Finally, there is concern regarding the level of community support for using SegWit versions as flags, particularly in relation to its impact on reaching agreement on BIP-360.

In essence, the conversation is centered on evaluating the trade-offs between adhering to traditional practices of version incrementation and adopting a more user-friendly, albeit unconventional, system of output identification. The outcome hinges on balancing technical feasibility, usability improvements, and community consensus.