<p>You differentiate a Taproot scriptPubKey and a P2WSH scriptPubKey by their witness version. <code>1</code> for Taproot, <code>0</code> for P2WSH.</p>
<p>A &quot;P2WSH with version 1&quot; doesn't exist, it would just be treated as a Taproot scriptPubKey by upgraded nodes (after activation) and as an anyone-can-spend by legacy ones.</p>
<pre><code>P2WSH: &lt;0&gt; &lt;32-bytes push&gt;
Taproot: &lt;1&gt; &lt;32-bytes push&gt;
</code></pre>
<hr />
<p>As for the mentioned funds loss i haven't heard about it but it's possible (if you send coins to <code>&lt;0&gt; &lt;random 32 bytes&gt;</code> you are going to burn your funds). In any case it <strong>would not be related to the address encoding</strong>, which is just an user interface.</p>

CC BY-SA 4.0
2021-06-01T17:50:40.893Z
Okay, that was what I was wondering - native segwit cannot use version 1 and above and subsequently do not use bech32m encodings (which is just a different checksum), else they are seen as invalid, (or a taproot address which is actually unspendable). 

I still don't fully understand what happend that caused P2TR "scripts" (pubkey, whatever you want to call it) encoded using standard bech32 (so checksum of 1) to burn funds because they were decoded wrong by wallets, if anyone could clarify the technicalities of that, and why that would be changed by bech32m, aside from breaking forwar-compat
jurgendonnings2321
CC BY-SA 4.0
2021-06-01T17:54:43.017Z
It's not whatever i want to call it, i try to use specific terms to not cause (additional) confusion (too many terms are already overloaded in Bitcoin-land). I don't know what you are talking about, could you provide a link to a discussion about this loss?
Antoine Poinsot
CC BY-SA 4.0
2021-06-01T17:58:37.937Z
All my sources are from the BIP readme detailing bech32m, so that would be [github](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#bech32m) and [this email](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html)
jurgendonnings2321
CC BY-SA 4.0
2021-06-01T18:38:15.720Z
Taproot outputs (P2TR) **are** native segwit v1 with 32-byte programs. That's how these outputs are defined. They're not "P2WSH v1", because P2WSH is defined as "Native or P2SH segwit v0 outputs with 32-byte programs".
Pieter Wuille
CC BY-SA 4.0
2021-06-01T18:42:48.543Z
The burning of funds was due to some services incorrectly implementing BIP173 in a way that resulted in bech32 v1+ addresses being turned into native v0 witness outputs (regardless of the version in the address). Taking a P2TR output (which stores a tweaked xonly pubkey) and changing the version to zero causes it to be interpreted as a P2WSH (with as script "hash" that tweaked key), which is unspendable.
Pieter Wuille
CC BY-SA 4.0
2021-06-01T18:56:16.430Z
Sorry, in that case I should indeed specify that by "native-segwit" in the first comment I was referring to the two "spending scripts" (again, not sure if correct terminology) currently used with witness version 0.

`Taking ... is unspendable` 

Okay fascinating, so they just sent to <0> <32-bytes push> instead of <1> <32-bytes push> because the version was hardcoded or similar on their end, and because that is actually just a valid P2WSH v0 encoding there was nothing that invalidated the payment? Think I got it.
jurgendonnings2321
CC BY-SA 4.0
2021-06-01T16:28:35.890Z
2021-11-13T20:49:57.137Z
2021-11-13T20:49:57.137Z
Antoine Poinsot
<p>Please correct me if i'm wrong:</p>
<p>So, with segwit v0 we know that 20 bytes is equal to P2WPKH, and 32 bytes is equal to P2WSH, and thus we can identify the address type by decoding the 31 byte or 43 byte bech-32 encoded string.</p>
<p>so we get decoded 0 &lt; hash of pubkey &gt; or 0 &lt; sha hash of redeem script &gt;, and identify the sender address type</p>
<p>Now I read that there has been some testing done with newer bech versions (bech32m) for P2WSH (or P2TR?) addresses, and also comments that some testing resulted in funds being lost, which confused me. (<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html</a>)</p>
<p>A) Considering funds got lost on mainnet using bech32m encoding (or was it p2tr v1+ using bech32?), am i correct in assuming that P2WPKH/S scripts can have a witness version of 1 (bech32m), else: how could this have been tested on mainnet (or can you generate valid p2tr addresses already, but just not spend from them? is that it?) -&gt; I guess that would make sense considering a v1 taproot address would look identical to a v1 P2WSH address?</p>
<p>-&gt;&gt; if so, how can we differentiate between script hashes of P2WSH 1 &lt;32 byte hash of redeem script&gt;, and taproot 1 &lt;public key 32 bytes&gt;</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#addresses-for-segregated-witness-outputs" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#addresses-for-segregated-witness-outputs</a></p>
<p>as address indication is done purely based on &quot;script size&quot;, and why is this not done in above link? Would this be considered &quot;unstandard&quot; - if so, why was there such an emphasis on testing this? I don't understand how this was a surprise?</p>
<p>B) If this is not the case and it was indeed P2TR adddresses which did not decode correctly using bech32, <strong>why then was this the case exactly</strong>, considering the only thing that bech32m changes is the checksum? As in; the decoding process did not change as a result of this BIP.</p>
<p>A quote from the BIP:</p>
<blockquote>
<p>This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.</p>
</blockquote>
<p>addresses using P2TR also have a restricted length, right?</p>

<bech32-address><bip350-bech32m>
Identifying address types using v1+ segwit outputs
jurgendonnings2321
# Identifying address types using v1+ segwit outputs

(Asked by: username_0 on 2021-06-01)

Please correct me if i'm wrong:

So, with segwit v0 we know that 20 bytes is equal to P2WPKH, and 32 bytes is equal to P2WSH, and thus we can identify the address type by decoding the 31 byte or 43 byte bech-32 encoded string.

so we get decoded 0 < hash of pubkey > or 0 < sha hash of redeem script >, and identify the sender address type

Now I read that there has been some testing done with newer bech versions (bech32m) for P2WSH (or P2TR?) addresses, and also comments that some testing resulted in funds being lost, which confused me. (<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html>)

A) Considering funds got lost on mainnet using bech32m encoding (or was it p2tr v1+ using bech32?), am i correct in assuming that P2WPKH/S scripts can have a witness version of 1 (bech32m), else: how could this have been tested on mainnet (or can you generate valid p2tr addresses already, but just not spend from them? is that it?) -> I guess that would make sense considering a v1 taproot address would look identical to a v1 P2WSH address?

->> if so, how can we differentiate between script hashes of P2WSH 1 <32 byte hash of redeem script>, and taproot 1 <public key 32 bytes>

<https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#addresses-for-segregated-witness-outputs>

as address indication is done purely based on "script size", and why is this not done in above link? Would this be considered "unstandard" - if so, why was there such an emphasis on testing this? I don't understand how this was a surprise?

B) If this is not the case and it was indeed P2TR adddresses which did not decode correctly using bech32, **why then was this the case exactly**, considering the only thing that bech32m changes is the checksum? As in; the decoding process did not change as a result of this BIP.

A quote from the BIP:

> This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.

addresses using P2TR also have a restricted length, right?

**Tags:** bech32-address, bip350-bech32m


---

## 1 answers

### Answer by username_1 on 2021-06-01. Score: 4 | Accepted answer

You differentiate a Taproot scriptPubKey and a P2WSH scriptPubKey by their witness version. `1` for Taproot, `0` for P2WSH.

A "P2WSH with version 1" doesn't exist, it would just be treated as a Taproot scriptPubKey by upgraded nodes (after activation) and as an anyone-can-spend by legacy ones.

```
P2WSH: <0> <32-bytes push>
Taproot: <1> <32-bytes push>

```

---

As for the mentioned funds loss i haven't heard about it but it's possible (if you send coins to `<0> <random 32 bytes>` you are going to burn your funds). In any case it **would not be related to the address encoding**, which is just an user interface.

> **Comments:**
> **username_0**: Okay, that was what I was wondering - native segwit cannot use version 1 and above and subsequently do not use bech32m encodings (which is just a different checksum), else they are seen as invalid, (or a taproot address which is actually unspendable).   I still don't fully understand what happend that caused P2TR "scripts" (pubkey, whatever you want to call it) encoded using standard bech32 (so checksum of 1) to burn funds because they were decoded wrong by wallets, if anyone could clarify the technicalities of that, and why that would be changed by bech32m, aside from breaking forwar-compat  
> **username_1**: It's not whatever i want to call it, i try to use specific terms to not cause (additional) confusion (too many terms are already overloaded in Bitcoin-land). I don't know what you are talking about, could you provide a link to a discussion about this loss?  
> **username_0**: All my sources are from the BIP readme detailing bech32m, so that would be [github](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#bech32m) and [this email](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html)  
> **username_2**: Taproot outputs (P2TR) **are** native segwit v1 with 32-byte programs. That's how these outputs are defined. They're not "P2WSH v1", because P2WSH is defined as "Native or P2SH segwit v0 outputs with 32-byte programs".  
> **username_2**: The burning of funds was due to some services incorrectly implementing BIP173 in a way that resulted in bech32 v1+ addresses being turned into native v0 witness outputs (regardless of the version in the address). Taking a P2TR output (which stores a tweaked xonly pubkey) and changing the version to zero causes it to be interpreted as a P2WSH (with as script "hash" that tweaked key), which is unspendable.  
> **username_0**: Sorry, in that case I should indeed specify that by "native-segwit" in the first comment I was referring to the two "spending scripts" (again, not sure if correct terminology) currently used with witness version 0.  `Taking ... is unspendable`   Okay fascinating, so they just sent to <0> <32-bytes push> instead of <1> <32-bytes push> because the version was hardcoded or similar on their end, and because that is actually just a valid P2WSH v0 encoding there was nothing that invalidated the payment? Think I got it.  

---

