<p>There are indeed 3 witness items, but only the first of them forms the initial stack. The second is the script itself (shown in disassembled form further on the page you linked to), and the third is the taproot control block (which proves how spending with this script is permitted by the output).</p>
<p>There are two kinds of P2TR spends:</p>
<ul>
<li>Key path spends, which have <em>exactly one</em> witness stack element.</li>
<li>Script path spends, which have <em>two or more</em> witness stack elements (the last one is the control block, the penultimate one the script, and all the ones before form the initial execution stack).</li>
</ul>
<p>Both of these can optionally have an <em>annex</em> as last element, which is ignored for the purposes of determining key path vs. script path spends. The annex is characterized by starting with byte 0x50.</p>

CC BY-SA 4.0
2023-12-10T02:50:19.173Z
2023-12-10T21:26:48.910Z
2023-12-10T21:26:48.910Z
Pieter Wuille
<p><a href="https://mempool.space/tx/ef64882653ffa84257d424c368bdf7be9d72ec34e602257f294b3fdc0a365e82" rel="nofollow noreferrer">This Taproot transaction</a> has 3 witness items which are initial stack for P2TR script. Execution of the tapscript goes something like this:</p>
<ol>
<li>push (4 items on the stack)</li>
<li><code>checksig</code> operation (results in pushing <code>1</code> on the stack - we are back on a 3 items on the stack)</li>
<li>push an empty element (4 items on the stack)</li>
<li><code>OP_IF</code> with an empty element as an input; it does not evaluate (3 items on the stack)</li>
<li>the end (3 items on the stack)</li>
</ol>
<p>Since the consensus rule for tapscript is that execution can't result in anything but exactly one element on the stack which evaluates to true, I am asking how is this transaction valid?</p>

<p2tr>
How is this P2TR transaction valid?
Cosmos
# How is this P2TR transaction valid?

(Asked by: username_0 on 2023-12-10)

[This Taproot transaction](https://mempool.space/tx/ef64882653ffa84257d424c368bdf7be9d72ec34e602257f294b3fdc0a365e82) has 3 witness items which are initial stack for P2TR script. Execution of the tapscript goes something like this:

1. push (4 items on the stack)
2. `checksig` operation (results in pushing `1` on the stack - we are back on a 3 items on the stack)
3. push an empty element (4 items on the stack)
4. `OP_IF` with an empty element as an input; it does not evaluate (3 items on the stack)
5. the end (3 items on the stack)

Since the consensus rule for tapscript is that execution can't result in anything but exactly one element on the stack which evaluates to true, I am asking how is this transaction valid?

**Tags:** p2tr


---

## 1 answers

### Answer by username_1 on 2023-12-10. Score: 2 | Accepted answer

There are indeed 3 witness items, but only the first of them forms the initial stack. The second is the script itself (shown in disassembled form further on the page you linked to), and the third is the taproot control block (which proves how spending with this script is permitted by the output).

There are two kinds of P2TR spends:

* Key path spends, which have *exactly one* witness stack element.
* Script path spends, which have *two or more* witness stack elements (the last one is the control block, the penultimate one the script, and all the ones before form the initial execution stack).

Both of these can optionally have an *annex* as last element, which is ignored for the purposes of determining key path vs. script path spends. The annex is characterized by starting with byte 0x50.


---

