It's an unfortunate side effect of the system's operation that this field is even legible in addresses, as doing so means funds senders think they need to police which ones are used which has a side effect of practically inhibiting users from self-selecting the rules that govern their own coins. It also presumes that different 'use types' map to different witness versions-- akin to the false belief that "3" addresses were multisig--, but this is a wrong assumption as the witness version is the product of technical minutia and not the user's application. It also creates needless competition for a limited resource. Why wouldn't *every* type be as compressed as reasonably possible? Why would there be only one kind of "resistant" address? It also presumes inflexible single use application-- but that isn't even inherent in the current limited functionality PQ schemes. For example, a hash tree signature scheme could easily be created that had a hidden branch in it that was "surprise, this branch is secretly a script commitment, and we're going to spend using the script!" in order to support taproot like "key-happy-path or script-fallback" that is revealed if the fallback is used. So I think this is undesirable and undermines the motivations of the existing design. On Fri, Jul 18, 2025 at 10:00 PM Ethan Heilman wrote: > I want to propose a new criteria for allocating Witness versions based on > human meaningfulness and see if there is support for this approach or if > the community is highly allergic to this idea. > > Bech32 (BIP-0173 > ) was > designed such that the Witness version is the first character in an address > after the “bc1” address prefix > > Witness Version 0: bc1q… > Witness Version 1: bc1p… > > Witness version 2: bc1z… > > Witness version 3: bc1r… > > Witness version 4: bc1y… > Witness version 5: bc19… > > Witness version 6: bc1x… > > Witness version 7: bc18… > > Witness version 8: bc1g… > > … > > So far we have been allocating Witness Versions in incrementing numeric > order (0,1,...). I want to suggest we allocate Witness Versions mnemonic to > make it easier to look at an address and determine the output type. > > This originally came up over the question of if BIP-360 should use Witness > Version 3 to get bc1r… for P2QRH (r for resistant) or the next numerically > available 2, but I want to see how the community feels about it as a > general pattern for future softforks (z for compressed/zipped output, y for > yield outputs, etc…). > > Making it easier for users to understand the output type associated is > likely to grow in importance over time as we retire output types, add > policy restricting the relay of certain output types or output types become > insecure due to cryptanalytic breaks. While wallet software should flag > dangerous output types, some wallets may not invest in such functionality > or the user may be using a paper wallet. This is the same argument as > prefixing addresses with “bc” for mainnet and “tc” for testnet. > > Note: the Witness version is sometimes called the SegWit version. > > Thanks, > Ethan > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com > > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTyRT9%2BECvhWvHR5niWSZkD0NgEW4kZLm1nPc8J5KezUg%40mail.gmail.com.