Hi Ethan,

I appreciate your intent behind making things easier for humans to understand, 
but I don't think it matters enough to break from the existing pattern of 
version incrementation. It's also a bit too late, given that quantum-vulnerable 
address types P2WKH and P2WSH already took the `bc1q` prefix.

More important will be other small minutiae like naming the output type (P2QRH? 
or P2TSH? or P2TTH? etc), and practical necessities like fully-defined 
post-quantum signature verification opcodes.

regards,
conduition
On Friday, July 18th, 2025 at 6:00 PM, Ethan Heilman <[email protected]> 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 [email protected].
> 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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/-k1KNMwmXrdmMxpxMeJHAOYuKpMfeUpx7rqfIkta_NC6f7MtzlOYEdXbAhi-SztejTidNysh40ask8j9JNrzxoh1sUCH4F9tKV6tarkrWrc%3D%40proton.me.

Attachment: publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to