user121961: 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?

user101498: 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.

121961: <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>
 101498: <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>
