<p>SegWit version 1 outputs with lengths other than 32 bytes remain unencumbered, which means their validation is unchanged and they remain anyone-can-spend. From <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules" rel="nofollow noreferrer">BIP341</a>:</p>
<blockquote>
<p>A Taproot output is a native SegWit output (see BIP141) with version
number 1, and a 32-byte witness program. The following rules only
apply when such an output is being spent. Any other outputs, including
version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped
version 1 outputs, remain unencumbered.</p>
</blockquote>
<p>Just like with Taproot, new validation rules for these outputs can later be added in a soft fork.</p>
<p>Note that this is different from SegWit version 0 outputs, which are unspendable if they aren't exactly 20 or 32 bytes.</p>
<p>In Bitcoin the consensus rules are basically a series of checks, and if all checks pass the transaction/block is valid.  A soft fork adds new checks, and &quot;unencumbered&quot; in this context means &quot;there are no new checks for this output type&quot;. If the output was previously anyone-can-spend, it will remain so.</p>

CC BY-SA 4.0
2023-11-23T17:08:06.847Z
2023-11-27T18:26:06.473Z
2023-11-27T18:26:06.473Z
Vojtěch Strnad
<p>If the witness program (at the time of writing this question) is greater than 1, it is considered as anyone-can-spend output. Also, if the witness version is 1 and the witness program is 32 bytes, then the output is encumbered with the taproot validation rules. In BIP341 it says that if the witness program is not exactly 32 bytes, the output remains unencumbered.</p>
<p>My question is, if it's not 32 bytes witness program and the witness version is 1, <strong>is it then anyone-can-spend output</strong>, so the soft fork can be done like in tapscript (when the public key is not 32 bytes, the signature opcode just passes without verification), or <strong>it is unspendable output</strong>?</p>
<p>Thank you!</p>

<segregated-witness><taproot><output><soft-fork><anyone-can-spend>
What would happen if we provide witness program different than 32 bytes for SegWit 1?
LeaBit
# What would happen if we provide witness program different than 32 bytes for SegWit 1?

(Asked by: username_0 on 2023-11-23)

If the witness program (at the time of writing this question) is greater than 1, it is considered as anyone-can-spend output. Also, if the witness version is 1 and the witness program is 32 bytes, then the output is encumbered with the taproot validation rules. In BIP341 it says that if the witness program is not exactly 32 bytes, the output remains unencumbered.

My question is, if it's not 32 bytes witness program and the witness version is 1, **is it then anyone-can-spend output**, so the soft fork can be done like in tapscript (when the public key is not 32 bytes, the signature opcode just passes without verification), or **it is unspendable output**?

Thank you!

**Tags:** segregated-witness, taproot, output, soft-fork, anyone-can-spend


---

## 1 answers

### Answer by username_1 on 2023-11-23. Score: 6 | Accepted answer

SegWit version 1 outputs with lengths other than 32 bytes remain unencumbered, which means their validation is unchanged and they remain anyone-can-spend. From [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules):

> A Taproot output is a native SegWit output (see BIP141) with version
> number 1, and a 32-byte witness program. The following rules only
> apply when such an output is being spent. Any other outputs, including
> version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped
> version 1 outputs, remain unencumbered.

Just like with Taproot, new validation rules for these outputs can later be added in a soft fork.

Note that this is different from SegWit version 0 outputs, which are unspendable if they aren't exactly 20 or 32 bytes.

In Bitcoin the consensus rules are basically a series of checks, and if all checks pass the transaction/block is valid. A soft fork adds new checks, and "unencumbered" in this context means "there are no new checks for this output type". If the output was previously anyone-can-spend, it will remain so.


---

