<p>From BIP 341,</p>
<blockquote>
<p><strong>Spending using one of the scripts:</strong> A Taproot output can be spent by satisfying any of the scripts used in its construction. To do so, a witness stack consisting of the script's inputs, plus the script itself and the control block are necessary.</p>
</blockquote>
<p>However, I don't see any mention of the limits in size or witness count explicitly. In BIP 342, following two resource limits are mentioned that are indirectly relevant (which weren't relaxed by the Taproot upgrade).</p>
<blockquote>
<p><strong>Stack + altstack element count limit:</strong> The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack.</p>
</blockquote>
<blockquote>
<p><strong>Stack element size limit:</strong> The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.</p>
</blockquote>
<p>Also, in BIP 341, on the section of Script Validation Rules, the last step is:</p>
<blockquote>
<p>Execute the script, according to the applicable script rules[11], using the witness stack elements excluding the script s, the control block c, and the annex a if present, as initial stack. This implies that for the future leaf versions (non-0xC0) the execution must succeed.[12].</p>
</blockquote>
<p>This means that only the script inputs are pushed to the stack during the script execution.</p>
<p>Does this all mean that there can be a maximum of 1000 script input items each with &lt;=520 bytes, with a total limit of 520 KB? And since the limit on initial stack was added by Taproot, this means that Taproot actually reduced the limit compared to before Taproot, and pre-segwit P2SH transactions could have unlimited script inputs (limited by block size/transaction size limit).</p>
<p>If this is the case, something like the Ordinal Inscriptions did not need Taproot to pack the big amounts of data into a Bitcoin transaction. This conclusion doesn't sound correct, but I don't know what I'm missing. Could someone enlighten me?</p>

CC BY-SA 4.0
2023-06-08T19:01:41.287Z
Ordinals predate inscriptions by many months, and Taproot predates ordinals by many years.
Mercedes
CC BY-SA 4.0
2023-06-23T04:05:06.503Z
@Mercedes Yes, but I'm trying to ask something entirely different. If someone wanted to pack <520 KB of data, could they do it with a different design than Ordinal Inscriptions, i.e. by using the rest of the witness rather than the script? With this alternative design, we can inscribe and reveal a piece of data using just one transaction, rather than two required by the Inscriptions.
Pramod Kandel
<bitcoin-core><taproot><transaction-weight><p2tr><ordinals>
Is there a limit on the number and size of script inputs when spending a script path in a P2TR transaction?
Pramod Kandel
# Is there a limit on the number and size of script inputs when spending a script path in a P2TR transaction?

(Asked by: username_0 on 2023-06-08)

From BIP 341,

> **Spending using one of the scripts:** A Taproot output can be spent by satisfying any of the scripts used in its construction. To do so, a witness stack consisting of the script's inputs, plus the script itself and the control block are necessary.

However, I don't see any mention of the limits in size or witness count explicitly. In BIP 342, following two resource limits are mentioned that are indirectly relevant (which weren't relaxed by the Taproot upgrade).

> **Stack + altstack element count limit:** The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack.

> **Stack element size limit:** The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.

Also, in BIP 341, on the section of Script Validation Rules, the last step is:

> Execute the script, according to the applicable script rules[11], using the witness stack elements excluding the script s, the control block c, and the annex a if present, as initial stack. This implies that for the future leaf versions (non-0xC0) the execution must succeed.[12].

This means that only the script inputs are pushed to the stack during the script execution.

Does this all mean that there can be a maximum of 1000 script input items each with <=520 bytes, with a total limit of 520 KB? And since the limit on initial stack was added by Taproot, this means that Taproot actually reduced the limit compared to before Taproot, and pre-segwit P2SH transactions could have unlimited script inputs (limited by block size/transaction size limit).

If this is the case, something like the Ordinal Inscriptions did not need Taproot to pack the big amounts of data into a Bitcoin transaction. This conclusion doesn't sound correct, but I don't know what I'm missing. Could someone enlighten me?

**Tags:** bitcoin-core, taproot, transaction-weight, p2tr, ordinals

> **Comments:**
> **username_1**: Ordinals predate inscriptions by many months, and Taproot predates ordinals by many years.  
> **username_0**: @username_1 Yes, but I'm trying to ask something entirely different. If someone wanted to pack <520 KB of data, could they do it with a different design than Ordinal Inscriptions, i.e. by using the rest of the witness rather than the script? With this alternative design, we can inscribe and reveal a piece of data using just one transaction, rather than two required by the Inscriptions.  

---

## 0 answers

