From: Ethan Heilman <eth3rs@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Human meaningful witness versioning
Date: Fri, 18 Jul 2025 17:58:46 -0400 [thread overview]
Message-ID: <CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
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
<https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>) 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.
[-- Attachment #2: Type: text/html, Size: 9680 bytes --]
next reply other threads:[~2025-07-18 22:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 21:58 Ethan Heilman [this message]
2025-07-18 22:18 ` [bitcoindev] Human meaningful witness versioning Greg Maxwell
2025-07-18 22:46 ` 'Ava Chow' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox