Delivery-date: Fri, 18 Jul 2025 15:56:31 -0700
Received-SPF: pass (google.com: domain of lists@achow101.com designates 79.135.106.25 as permitted sender) client-ip=79.135.106.25;
Date: Fri, 18 Jul 2025 22:46:38 +0000
To: bitcoindev@googlegroups.com
From: "'Ava Chow' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Human meaningful witness versioning
Message-ID: <d5b68a7e-0eea-465d-95f5-9cb6557697d8@achow101.com>
In-Reply-To: <CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com>
References: <CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com>
Feedback-ID: 53660394:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: Ava Chow <lists@achow101.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Ethan,

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

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

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

We have already seen such a proposal be deployed - Pay to Anchor outputs=20
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=20
lose the ability to define new rules for different sized witness=20
programs of already in use witness versions. Such usage would cause=20
mnemonics to lose their meaning, unless we expect users to also be=20
checking the length of addresses, and I don't think that's a reasonable=20
expectation.

Ava

On 07/18/2025 02:58 PM, Ethan Heilman wrote:
> I want to propose a new criteria for allocating Witness versions based=20
> on human meaningfulness and see if there is support for this approach or=
=20
> if the community is highly allergic to this idea.
>=20
> Bech32 (BIP-0173 <https://github.com/bitcoin/bips/blob/master/=20
> bip-0173.mediawiki>) was designed such that the Witness version is the=20
> first character in an address after the =E2=80=9Cbc1=E2=80=9D address pre=
fix
>=20
> Witness Version 0: bc1q=E2=80=A6
> Witness Version 1: bc1p=E2=80=A6
>=20
> Witness version 2: bc1z=E2=80=A6
>=20
> Witness version 3: bc1r=E2=80=A6
>=20
> Witness version 4: bc1y=E2=80=A6
> Witness version 5: bc19=E2=80=A6
>=20
> Witness version 6: bc1x=E2=80=A6
>=20
> Witness version 7: bc18=E2=80=A6
>=20
> Witness version 8: bc1g=E2=80=A6
>=20
> =E2=80=A6
>=20
>=20
> So far we have been allocating Witness Versions in incrementing numeric=
=20
> order (0,1,...). I want to suggest we allocate Witness Versions mnemonic=
=20
> to make it easier to look at an address and determine the output type.
>=20
>=20
> This originally came up over the question of if BIP-360 should use=20
> Witness Version 3 to get bc1r=E2=80=A6 for P2QRH (r for resistant) or the=
 next=20
> numerically available 2, but I want to see how the community feels about=
=20
> it as a general pattern for future softforks (z for compressed/zipped=20
> output, y for yield outputs, etc=E2=80=A6).
>=20
>=20
> Making it easier for users to understand the output type associated is=20
> likely to grow in importance over time as we retire output types, add=20
> policy restricting the relay of certain output types or output types=20
> become insecure due to cryptanalytic breaks. While wallet software=20
> should flag dangerous output types, some wallets may not invest in such=
=20
> functionality or the user may be using a paper wallet. This is the same=
=20
> argument as prefixing addresses with =E2=80=9Cbc=E2=80=9D for mainnet and=
 =E2=80=9Ctc=E2=80=9D for testnet.
>=20
>=20
> Note: the Witness version is sometimes called the SegWit version.
>=20
> Thanks,
> Ethan
>=20
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to bitcoindev+unsubscribe@googlegroups.com=20
> <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/=20
> bitcoindev/=20
> CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com=
=20
> <https://groups.google.com/d/msgid/bitcoindev/=20
> CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com?=
utm_medium=3Demail&utm_source=3Dfooter>.


--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
d5b68a7e-0eea-465d-95f5-9cb6557697d8%40achow101.com.