Re: [bitcoindev] Human meaningful witness versioning

[Ethan Heilman <eth3rs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4890 bytes --]

When I was trying to understand BIP 0173, I came up with five ways to do it:

1.  Don't treat the Witness version as a special part of the address. Just
encode the ScriptPubkey.

2. (Bech32 approach) allocate the first 5-bits to Witness version. This
lets you do versions 0 to 31 before the Witness version spills into the
next character.  As you note this saves 3-bits, because you are compressing
the 8-bit opcode into 5-bits.

3. You could take the Bech32 approach a little further and save an
additional 8-bits by not including the OP_PUSH32 and just inferring it from
address length. Granted this length inference would present issues if we
want to do more complex things in the ScriptPubkey, but we could handle
these cases with Witness versions like we do with bech32 and bech32m.

4. Allocate first 4-bits to Witness version. This lets you do 0 to 15
before the Witness version spills into the next character.

5. Put checksum as the first character after bc1 so the Witness version
isn't the next character after the human readable component of the address.
This would discourage people viewing the Witness version as part of the
human readable component.

1,4,5 obscures the witness version. 3, does not obscure the witness version
but saves at least one character. Why compress the Witness version to fit
into 5-bits but not the OP_PUSH32 (or OP_PUSH20)? My assumption until today
was that the original reason for 2 was to make the Witness version human
readable, but since that isn't the case and it was just about the number of
characters, why not drop the OP_PUSH?

Option 5 and dropping OP_PUSH32 seems best to avoid address confusion.

> The reason it's 5 bits is just to avoid needlessly inflating the length
of addresses.. as additional versioning, if someday required could be
achieved by additional words in the payload.

How would we encode the Witness version beyond 16, `OP_16, OP_0, OP_PUSH32,
32 bytes` or `OP_PUSH0, 0x00, OP_PUSH32, 32 bytes`?

On Sun, Jul 20, 2025, 18:38 Greg Maxwell <gmaxwell@gmail.com> wrote:

> On Sun, Jul 20, 2025 at 9:35 PM Ethan Heilman <eth3rs@gmail.com> wrote:
>
>> Does anyone remember why BIP-0173 added a special rule to make Witness
>> Versions legible in this way? It might be useful to document here for
>> future discussions on address encoding.
>>
>
> I'm not sure what you're referring to there -- there needed to be an
> _encoded_ version for the purpose of consensus rules.  1xxx addresses have
> one, for example (which results in them beginning with 1).  The reason it's
> 5 bits is just to avoid needlessly inflating the length of addresses.. as
> additional versioning, if someday required could be achieved by additional
> words in the payload.
>
> There is a _human readable_ part, but that refers to the "bc" prefix
> identifying the currency/network,  not any of the technical minutia about
> how the system works.  The reason for the human readable part was that
> there has been instances of funds loss caused by fork coins / altcoins that
> copied bitcoin wholesale and used the same addresses and we'd hoped that a
> prefix that was easy to change an unambiguously associated with bitcoin
> would have a chance of reducing that risk in the future.
>
> or to restate: A recipient's script is fundamentally none of the sender's
> business (except for multiparty contracts or other special cases) -- and so
> generally we want the sender to be as oblivious of the details of the
> script as reasonably possible.  If the sender has paid to the output the
> receiver has specified then they've done their part.  Any further issues
> are the recipient's responsibility.  If the sender hasn't-- e.g. say they
> took apart some address and made some custom script without the receivers
> consent, like turning a taproot pubkey into a legacy address-- then they
> haven't made a payment to the recipient and they still owe the
> recipient funds.  But this also requires that the payment be on the right
> network, and while they could be informed outside of the address since it
> was a frequent cause of errors we thought it critical to embed it.  The
> reason for making the embedding legible was primarily so that altcoins
> wouldn't just copy the prefix as they had frequently done with the version
> numbers.
>
> (and I believe so far this has proved to be successful, copies have
> changed the HRP)
>
>
>
>
>
>
>
>
>
>

-- 
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%2BUJJ9R5ACxNg%3DB2HcnBZMxf%2BKoWtkvH1yFgRcU56hms8g%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6316 bytes --]