[bitcoindev] Human meaningful witness versioning

[bitcoindev] Human meaningful witness versioning

[Ethan Heilman]

[-- 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 --]

Re: [bitcoindev] Human meaningful witness versioning

[Greg Maxwell]

[-- 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 --]

Re: [bitcoindev] Human meaningful witness versioning

['Ava Chow' via Bitcoin Development Mailing List]

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.

Re: [bitcoindev] Human meaningful witness versioning

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1.1: Type: text/plain, Size: 3361 bytes --]

Hi Ethan,

I appreciate your intent behind making things easier for humans to understand, but I don't think it matters enough to break from the existing pattern of version incrementation. It's also a bit too late, given that quantum-vulnerable address types P2WKH and P2WSH already took the `bc1q` prefix.

More important will be other small minutiae like naming the output type (P2QRH? or P2TSH? or P2TTH? etc), and practical necessities like fully-defined post-quantum signature verification opcodes.

regards,
conduition
On Friday, July 18th, 2025 at 6: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) 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.

-- 
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/-k1KNMwmXrdmMxpxMeJHAOYuKpMfeUpx7rqfIkta_NC6f7MtzlOYEdXbAhi-SztejTidNysh40ask8j9JNrzxoh1sUCH4F9tKV6tarkrWrc%3D%40proton.me.

[-- Attachment #1.1.2.1: Type: text/html, Size: 11864 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [bitcoindev] Human meaningful witness versioning

[Ethan Heilman]

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

Thanks everyone. Given that so far everyone else is opposed, BIP-360 will
use Witness Version 2.

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.



On Sun, Jul 20, 2025 at 11:19 AM conduition <conduition@proton.me> wrote:

> Hi Ethan,
>
> I appreciate your intent behind making things easier for humans to
> understand, but I don't think it matters enough to break from the existing
> pattern of version incrementation. It's also a bit too late, given that
> quantum-vulnerable address types P2WKH and P2WSH already took the bc1q​
> prefix.
>
> More important will be other small minutiae like naming the output type
> (P2QRH? or P2TSH? or P2TTH? etc), and practical necessities like
> fully-defined post-quantum signature verification opcodes.
>
> regards,
> conduition
> On Friday, July 18th, 2025 at 6: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
> .
>
>
>

-- 
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%2BWUpbzJBU6nYyM5Lj3ByD199Fxubvc50uqkv8uEd7GJtA%40mail.gmail.com.

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

Re: [bitcoindev] Human meaningful witness versioning

[Greg Maxwell]

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

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/CAAS2fgR%2BXccLeZqt0GXP%3Db-cu9ya%3D-pVZred_q6xGCrNKMLy9g%40mail.gmail.com.

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

Re: [bitcoindev] Human meaningful witness versioning

[Ethan Heilman]

[-- 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 --]