<p>This is a consensus rule inside (P2SH-)P2WSH witness scripts, and P2TR script-path spends already.</p>
<p>See <a href="https://github.com/bitcoin/bips/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141</a>:</p>
<blockquote>
<p>The script must not fail, and result in exactly a single TRUE on the stack.</p>
</blockquote>
<p>And <a href="https://github.com/bitcoin/bips/bip-0342.mediawiki" rel="nofollow noreferrer">BIP342</a>:</p>
<blockquote>
<p>If the execution results in anything but exactly one element on the stack which evaluates to true with <code>CastToBool()</code>, fail.</p>
</blockquote>
<hr />
<p>It would be possible to do a soft fork to enforce this rule for bare scripts and P2SH scripts too, though as you note, doing this naively would interfere with segwit script matching. A potential solution would be to exclude these patterns from the rule, but that may still be undesirable as it would close the door to using similar script extension mecanisms in the future. This was not an issue at the time BIP62 was proposed, as it predated segwit, but still, in retrospect it is probably good that it didn't get adopted as consensus rule.</p>
<p>I think there is little reason to add this rule to bare scripts and even P2SH scripts, as they are effectively obsolete. Newer constructions are cheaper, more compact, more convenient, and offer more features.</p>

CC BY-SA 4.0
2024-01-20T18:07:38.093Z
2024-01-20T21:40:32.780Z
2024-01-20T21:40:32.780Z
Pieter Wuille
<p>In BIP62, it was proposed to make a script invalid if there was more than one element left in the stack after execution. This proposal was eventually withdrawn.</p>
<p>From what I read, some people have suggested that this rule could eventually be enforced in the future. But the problem is that I think this would make segwit outputs non-valid with legacy nodes?</p>
<p>Take a P2TR for example. To a legacy node, the locking script of a P2TR output is seen as two non-zero data pushes. Together with the unlocking script (an empty byte array), this would leave the stack with two non-zero data pushes after execution, so a P2TR transaction would be rejected by legacy nodes.</p>
<p>Am I missing something?</p>

<script><segregated-witness><consensus><p2tr><bip62>
Are there plans to make a script invalid if there is more than one element left in the stack?
mathboi
# Are there plans to make a script invalid if there is more than one element left in the stack?

(Asked by: username_0 on 2024-01-20)

In BIP62, it was proposed to make a script invalid if there was more than one element left in the stack after execution. This proposal was eventually withdrawn.

From what I read, some people have suggested that this rule could eventually be enforced in the future. But the problem is that I think this would make segwit outputs non-valid with legacy nodes?

Take a P2TR for example. To a legacy node, the locking script of a P2TR output is seen as two non-zero data pushes. Together with the unlocking script (an empty byte array), this would leave the stack with two non-zero data pushes after execution, so a P2TR transaction would be rejected by legacy nodes.

Am I missing something?

**Tags:** script, segregated-witness, consensus, p2tr, bip62


---

## 1 answers

### Answer by username_1 on 2024-01-20. Score: 2 | Accepted answer

This is a consensus rule inside (P2SH-)P2WSH witness scripts, and P2TR script-path spends already.

See [BIP141](https://github.com/bitcoin/bips/bip-0141.mediawiki):

> The script must not fail, and result in exactly a single TRUE on the stack.

And [BIP342](https://github.com/bitcoin/bips/bip-0342.mediawiki):

> If the execution results in anything but exactly one element on the stack which evaluates to true with `CastToBool()`, fail.

---

It would be possible to do a soft fork to enforce this rule for bare scripts and P2SH scripts too, though as you note, doing this naively would interfere with segwit script matching. A potential solution would be to exclude these patterns from the rule, but that may still be undesirable as it would close the door to using similar script extension mecanisms in the future. This was not an issue at the time BIP62 was proposed, as it predated segwit, but still, in retrospect it is probably good that it didn't get adopted as consensus rule.

I think there is little reason to add this rule to bare scripts and even P2SH scripts, as they are effectively obsolete. Newer constructions are cheaper, more compact, more convenient, and offer more features.


---

