<p>The only thing Taproot changed with respect to the &quot;inscription envelope&quot; is removing the script size limit, which was previously 10,000 bytes for P2WSH and 520 bytes for P2SH. In P2TR, the scripts are only implicitly bounded by the block weight limit.</p>
<p>However, there's nothing stopping you from storing data smaller than 10,000 bytes in P2WSH (it's even slightly cheaper), or splitting larger data across multiple inputs in chunks of 10,000 (which would be slightly more expensive).</p>

CC BY-SA 4.0
2024-04-04T11:34:25.843Z
2024-04-04T11:34:25.843Z
Vojtěch Strnad
<p>I don't quite understand how ordinals are able to store so much data on chain. I know about the ordinals envelope.</p>
<pre><code>OP_FALSE 
OP_IF
   OP_PUSH &quot;ord&quot;
   OP_PUSH 1
   OP_PUSH &quot;text/plain;charset=utf-8&quot;
   OP_PUSH 0
   OP_PUSH &quot;Hello, world!&quot;
 OP_ENDIF  
</code></pre>
<p>According to the ordinals handbook, in this example, the text &quot;Hello, world!&quot; is stored on chain. But I thought that the taproot upgrade simply enables people to tweak the public key to embed a merkle root on chain by tweaking the public key to create a modified address. Even then, the merkle root isn't actually stored on chain. You just have to know it to spend coins from that address right?</p>
<p>I know my understanding is wrong because if all you needed to know to spend coins from the script path was the merkle root you wouldn't need to know the hash of any of the leaves.</p>
<p>I know that bitcoin transactions have some code for scripting in the actual hexadecimal transaction. For example a simple locking script in a bitcoin transaction output looks like this &quot;scriptPubKey&quot;: &quot;OP_DUP OP_HASH160 HASH_OF_PUBKEY_IN_HEX OP_EQUALVERIFY OP_CHECKSIG&quot; so to spend that transaction whoever has the private key of the address in the UTXO provides an unlocking script consisting of the signature and public key. But this is just a little bit of data that bitcoin transactions store, how does taproot allow for such larger amounts of data to be stored?</p>

<taproot><merkle-tree><p2tr><ordinals>
How can taproot transactions manage to store so much data?
ChristianOConnor
# How can taproot transactions manage to store so much data?

(Asked by: username_0 on 2024-04-04)

I don't quite understand how ordinals are able to store so much data on chain. I know about the ordinals envelope.

```
OP_FALSE 
OP_IF
   OP_PUSH "ord"
   OP_PUSH 1
   OP_PUSH "text/plain;charset=utf-8"
   OP_PUSH 0
   OP_PUSH "Hello, world!"
 OP_ENDIF  

```

According to the ordinals handbook, in this example, the text "Hello, world!" is stored on chain. But I thought that the taproot upgrade simply enables people to tweak the public key to embed a merkle root on chain by tweaking the public key to create a modified address. Even then, the merkle root isn't actually stored on chain. You just have to know it to spend coins from that address right?

I know my understanding is wrong because if all you needed to know to spend coins from the script path was the merkle root you wouldn't need to know the hash of any of the leaves.

I know that bitcoin transactions have some code for scripting in the actual hexadecimal transaction. For example a simple locking script in a bitcoin transaction output looks like this "scriptPubKey": "OP\_DUP OP\_HASH160 HASH\_OF\_PUBKEY\_IN\_HEX OP\_EQUALVERIFY OP\_CHECKSIG" so to spend that transaction whoever has the private key of the address in the UTXO provides an unlocking script consisting of the signature and public key. But this is just a little bit of data that bitcoin transactions store, how does taproot allow for such larger amounts of data to be stored?

**Tags:** taproot, merkle-tree, p2tr, ordinals


---

## 1 answers

### Answer by username_1 on 2024-04-04. Score: 3 | Accepted answer

The only thing Taproot changed with respect to the "inscription envelope" is removing the script size limit, which was previously 10,000 bytes for P2WSH and 520 bytes for P2SH. In P2TR, the scripts are only implicitly bounded by the block weight limit.

However, there's nothing stopping you from storing data smaller than 10,000 bytes in P2WSH (it's even slightly cheaper), or splitting larger data across multiple inputs in chunks of 10,000 (which would be slightly more expensive).


---

