<blockquote>
<p>I am not sure if I confuse the address format prefix bc1 with the witness version.</p>
</blockquote>
<p>You are confusing them. &quot;bc1&quot; is the prefix. The witness version is part of the bech32/bech32m payload; specifically, the next character <em>after</em> the &quot;1&quot; encodes the witness version.</p>
<blockquote>
<p>P2WPKH, P2WSH have witness version 0 indicated by the yellow part shown below. If witness version is 0, a SegWit node looks at the size of the byte-key-hash to determine if it is a P2WPKH (20B) or P2WSH(32B).</p>
</blockquote>
<p>This is correct.</p>
<blockquote>
<p>P2WPKH wrapped in P2SH and P2WSH wrapped in P2SH does not have a witness version byte in the scriptPubKey. Why is that?</p>
</blockquote>
<p>In P2SH-wrapped P2WPKH/P2WSH the scriptPubKey encodes only a hash of the witness program (the OP_(version) + data push). The actual witness program (including the witness version) is only revealed at spending time.</p>
<blockquote>
<p>According to BIP350, bech32 has witness version 0 and bech32m has witness version.</p>
</blockquote>
<p>Almost. You cannot tell bech32 from bech32m strings by just looking at them. However, in the context of native segwit addresses, bech32 <em>has</em> to be used for witness 0, and bech32m <em>has</em> to be used for witness 1 and higher.</p>
<p>So in general the strategy is to try decoding every address as both bech32 and bech32m, see if either is valid, then check if the payload encodes a valid segwit address, find its version, and finally check that the version matches the address encoding (bech32 for 0, bech32m for other versions).</p>
<p>This is mostly unrelated to your question though. The encoding is structured as follows (for both bech32 and bech32m; the only difference between the two is the checksum):</p>
<ul>
<li>First there is the <strong>human readable part</strong>.
<ul>
<li>For mainnet native segwit addresses (v0 or later), the human readable part is &quot;bc&quot;.</li>
</ul>
</li>
<li>Then there is the <strong>separator</strong>. The separator is always <em>exactly</em> &quot;1&quot;.</li>
<li>Then there is the <strong>payload</strong>, consisting of a variable number of base32 characters.
<ul>
<li>For native segwit addresses (v0 or later), the payload consists of one character that encodes the witness version (v0 = &quot;p&quot;, v1 = &quot;q&quot;, v2 = &quot;z&quot;, ...), followed by 4 to 64 characters that encode the 2 to 40 byte push in the witness program (the data pushed after the OP_(version)).</li>
</ul>
</li>
<li>Lastly there are 6 base32 characters that form a <strong>checksum</strong> over the whole thing.</li>
</ul>
<blockquote>
<p>P2TR introduces new opcodes and therefore, it should introduce a new witness version, is that correct?</p>
</blockquote>
<p>Indeed, P2TR uses witness programs that consist of OP_1 + a 32-byte push, and are thus witness version 1. In BIP350 addresses, that translates to a &quot;p&quot; after the separator (as opposed to version 0 P2WPKH/P2WSH, which have a &quot;q&quot; after the sepatator).</p>

CC BY-SA 4.0
2021-12-03T15:45:29.380Z
2021-12-03T15:51:50.353Z
2021-12-03T15:51:50.353Z
Pieter Wuille
<p>I don't fully understand the meaning of the witness version byte. I am not sure if I confuse the address format prefix <code>bc1</code> with the witness version.</p>
<p>My understanding: The extra byte reserved for the witness version indicates what opcodes are used for evaluating the spending script (<code>scriptPubKey</code>).</p>
<ul>
<li><strong>P2WPKH</strong>, <strong>P2WSH</strong> have witness version <code>0</code> indicated by the yellow part shown below. If witness version is 0, a SegWit node looks at the size of the <code>byte-key-hash</code> to determine if it is a P2WPKH (20B) or P2WSH(32B).</li>
</ul>
<p><a href="https://i.sstatic.net/gj5HX.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/gj5HX.png" alt="enter image description here" /></a></p>
<ul>
<li><strong>P2WPKH wrapped in P2SH</strong> and <strong>P2WSH wrapped in P2SH</strong> does not have a witness version byte in the <code>scriptPubKey</code>. Why is that?</li>
</ul>
<p><a href="https://i.sstatic.net/sa9eY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sa9eY.png" alt="enter image description here" /></a></p>
<ul>
<li><p>According to <a href="https://bips.xyz/350#addresses-for-segregated-witness-outputs" rel="nofollow noreferrer">BIP350</a>, <strong>bech32</strong> has witness version <code>0</code> and <strong>bech32m</strong> has witness version. Does the <code>1</code> in bc<strong>1</strong>... indicate the witness version? If so, why are there are no bc<strong>0</strong> addresses? Where is my thought process wrong? Do I mix address prefixes with witness versions?</p>
</li>
<li><p><strong>P2TR</strong> introduces new opcodes and therefore, it should introduce a new witness version, is that correct? But P2TP addresses start with bc1...</p>
</li>
</ul>

<address><bech32-address>
Witness Version bech32 and P2TR
sibabtcs
# Witness Version bech32 and P2TR

(Asked by: username_0 on 2021-12-03)

I don't fully understand the meaning of the witness version byte. I am not sure if I confuse the address format prefix `bc1` with the witness version.

My understanding: The extra byte reserved for the witness version indicates what opcodes are used for evaluating the spending script (`scriptPubKey`).

* **P2WPKH**, **P2WSH** have witness version `0` indicated by the yellow part shown below. If witness version is 0, a SegWit node looks at the size of the `byte-key-hash` to determine if it is a P2WPKH (20B) or P2WSH(32B).

[![enter image description here](https://i.sstatic.net/gj5HX.png)](https://i.sstatic.net/gj5HX.png)

* **P2WPKH wrapped in P2SH** and **P2WSH wrapped in P2SH** does not have a witness version byte in the `scriptPubKey`. Why is that?

[![enter image description here](https://i.sstatic.net/sa9eY.png)](https://i.sstatic.net/sa9eY.png)

* According to [BIP350](https://bips.xyz/350#addresses-for-segregated-witness-outputs), **bech32** has witness version `0` and **bech32m** has witness version. Does the `1` in bc**1**... indicate the witness version? If so, why are there are no bc**0** addresses? Where is my thought process wrong? Do I mix address prefixes with witness versions?
* **P2TR** introduces new opcodes and therefore, it should introduce a new witness version, is that correct? But P2TP addresses start with bc1...

**Tags:** address, bech32-address


---

## 1 answers

### Answer by username_1 on 2021-12-03. Score: 1

> I am not sure if I confuse the address format prefix bc1 with the witness version.

You are confusing them. "bc1" is the prefix. The witness version is part of the bech32/bech32m payload; specifically, the next character *after* the "1" encodes the witness version.

> P2WPKH, P2WSH have witness version 0 indicated by the yellow part shown below. If witness version is 0, a SegWit node looks at the size of the byte-key-hash to determine if it is a P2WPKH (20B) or P2WSH(32B).

This is correct.

> P2WPKH wrapped in P2SH and P2WSH wrapped in P2SH does not have a witness version byte in the scriptPubKey. Why is that?

In P2SH-wrapped P2WPKH/P2WSH the scriptPubKey encodes only a hash of the witness program (the OP\_(version) + data push). The actual witness program (including the witness version) is only revealed at spending time.

> According to BIP350, bech32 has witness version 0 and bech32m has witness version.

Almost. You cannot tell bech32 from bech32m strings by just looking at them. However, in the context of native segwit addresses, bech32 *has* to be used for witness 0, and bech32m *has* to be used for witness 1 and higher.

So in general the strategy is to try decoding every address as both bech32 and bech32m, see if either is valid, then check if the payload encodes a valid segwit address, find its version, and finally check that the version matches the address encoding (bech32 for 0, bech32m for other versions).

This is mostly unrelated to your question though. The encoding is structured as follows (for both bech32 and bech32m; the only difference between the two is the checksum):

* First there is the **human readable part**.
  + For mainnet native segwit addresses (v0 or later), the human readable part is "bc".
* Then there is the **separator**. The separator is always *exactly* "1".
* Then there is the **payload**, consisting of a variable number of base32 characters.
  + For native segwit addresses (v0 or later), the payload consists of one character that encodes the witness version (v0 = "p", v1 = "q", v2 = "z", ...), followed by 4 to 64 characters that encode the 2 to 40 byte push in the witness program (the data pushed after the OP\_(version)).
* Lastly there are 6 base32 characters that form a **checksum** over the whole thing.

> P2TR introduces new opcodes and therefore, it should introduce a new witness version, is that correct?

Indeed, P2TR uses witness programs that consist of OP\_1 + a 32-byte push, and are thus witness version 1. In BIP350 addresses, that translates to a "p" after the separator (as opposed to version 0 P2WPKH/P2WSH, which have a "q" after the sepatator).


---

