* [bitcoindev] Human meaningful witness versioning
@ 2025-07-18 21:58 Ethan Heilman
2025-07-18 22:18 ` Greg Maxwell
2025-07-18 22:46 ` 'Ava Chow' via Bitcoin Development Mailing List
0 siblings, 2 replies; 3+ messages in thread
From: Ethan Heilman @ 2025-07-18 21:58 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Human meaningful witness versioning
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
1 sibling, 0 replies; 3+ messages in thread
From: Greg Maxwell @ 2025-07-18 22:18 UTC (permalink / raw)
To: Ethan Heilman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4287 bytes --]
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 <eth3rs@gmail•com> 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.
> 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/CAAS2fgTyRT9%2BECvhWvHR5niWSZkD0NgEW4kZLm1nPc8J5KezUg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12316 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Human meaningful witness versioning
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
1 sibling, 0 replies; 3+ messages in thread
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2025-07-18 22:46 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-18 22:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox