public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "'Ava Chow' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Human meaningful witness versioning
Date: Fri, 18 Jul 2025 22:46:38 +0000	[thread overview]
Message-ID: <d5b68a7e-0eea-465d-95f5-9cb6557697d8@achow101.com> (raw)
In-Reply-To: <CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com>

Hi Ethan,

I do not think that this is a good idea, and it undermines one of the 
ways that witness programs provide us flexibility when deploying soft 
forks in the form of varying witness program lengths.

Both witness version 0 and version 1 define consensus rules for the pair 
of witness version and size of the witness program. A P2WPKH address and 
a P2WSH address have very different meanings, yet share the same witness 
version and therefore the same bc1q prefix. Their different rules are 
applied depending on the size of the witness program.

While BIP 141 explicitly disallows the disallows the usage of other 
sizes when it defined version 0, BIP 341 made no such restrictions on 
version 1. Instead, the rules defined in BIP 341 only apply to witness 
programs of 32 bytes, thus allowing new rules to be applied to witness 
programs of other sizes that are also version 1.

We have already seen such a proposal be deployed - Pay to Anchor outputs 
use witness version 1 with a 2 byte witness program of a particular value.

If the witness version were chosen based on a mnemonic, then we largely 
lose the ability to define new rules for different sized witness 
programs of already in use witness versions. Such usage would cause 
mnemonics to lose their meaning, unless we expect users to also be 
checking the length of addresses, and I don't think that's a reasonable 
expectation.

Ava

On 07/18/2025 02:58 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 <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 
> <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/ 
> bitcoindev/ 
> CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com 
> <https://groups.google.com/d/msgid/bitcoindev/ 
> CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com?utm_medium=email&utm_source=footer>.


-- 
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/d5b68a7e-0eea-465d-95f5-9cb6557697d8%40achow101.com.


      parent reply	other threads:[~2025-07-18 22:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18 21:58 [bitcoindev] Human meaningful witness versioning Ethan Heilman
2025-07-18 22:18 ` Greg Maxwell
2025-07-18 22:46 ` 'Ava Chow' via Bitcoin Development Mailing List [this message]

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=d5b68a7e-0eea-465d-95f5-9cb6557697d8@achow101.com \
    --to=bitcoindev@googlegroups.com \
    --cc=lists@achow101.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