<p>A taproot script path spend always has at least 2 witness items:</p>
<ul>
<li>The second-to-last item is the leaf script.</li>
<li>The last item is the &quot;control block&quot; which consists of a leaf version, the taproot internal key (the public key before it was tweaked with the merkle root of the script tree) and optionally any merkle branches that prove the inclusion of the script in the tree. These are not present here because the tree only has one script (this might be required by the inscription standard, haven't checked).</li>
<li>Any remaining items are used as the initial stack for script execution. In this case the single remaining item is the signature that satisfies the OP_CHECKSIG opcode.</li>
</ul>
<p>The public key <code>1809cc80..af8f</code> is used both as an internal key and in the script. This would normally hurt privacy because you reveal that the key path has the same key as the script path, but in the case of inscriptions it doesn't really matter because you already reveal you weren't going to use the key path, and it probably simplifies the code a little.</p>

CC BY-SA 4.0
2023-05-10T12:12:59.700Z
2023-05-10T12:12:59.700Z
Vojtěch Strnad
<p>I think Vojtěch Strnad answered your main questions, I just wanted to point out how the inscribed data is encoded:</p>
<p>You wrote:</p>
<blockquote>
<pre><code>OP_PUSHBYTES_32
1809cc80b0c9bf0277e774f7f78c5dd0c61f9eda7bec7875dc99457bbf61af8f
OP_CHECKSIG 
OP_0 
OP_IF 
OP_PUSHBYTES_3 6582895
</code></pre>
</blockquote>
<p>Those three bytes are hex <code>6F7264</code> which is ASCII   <code>ord</code> meaning the Ordinals project.</p>
<blockquote>
<pre><code>OP_PUSHBYTES_1 1
OP_PUSHBYTES_23 746578742f68746d6c3b636861727365743d7574662d38 
</code></pre>
</blockquote>
<p>Those 23 bytes are <code>text/html;charset=utf-8</code> - the type of data inscribed</p>
<blockquote>
<pre><code>OP_0
OP_PUSHDATA2 520
3c21444f43545950452068746d6c3e3c68746d6c3e3c686561643e3c7469746c653e59657420416e6f74686572
</code></pre>
</blockquote>
<p>Those 520 bytes are HTML (as indicated previously):</p>
<p><code>&lt;!DOCTYPE html&gt;&lt;html&gt;&lt;head&gt;&lt;title&gt;Yet Another Doom Clone&lt;/title&gt;&lt;/head&gt;&lt;body&gt;&lt;style&gt;body{margin:0px;background:#000}#qQ{position:absolute;left:35vw;top:4em;font-size:2em;font-variant:small-caps;color:#aaa;animation:z 9s;}#cQ{height:100%;width:100%}#hQ{top:0px;width:10vw;height:2vh;border:3px solid #008;border-radius:3px;display:none}#fps{display:none}#hW{height:2vh;background:#00a}@keyframes q{50%{opacity:0}}.b{animation:q 1s linear infinite}@keyframes z{from{opacity:0}to{opacity:1}}&lt;/style&gt;&lt;canvas id=cQ&gt;&lt;/canvas&gt;&lt;Mdiv id=qQ&gt;&lt;div id=hE&gt;Yet Another Doom Clone&lt;br&gt;&lt;br&gt;&lt;div class=b&gt;Loading... &lt;span id=jQ&gt;&lt;/span&gt;&lt;/div&gt;&lt;br&gt;&lt;br&gt;Move: WASD&lt;br&gt;Aim/Shoot: Mouse/Click&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;By Nicholas Carlini&lt;/div&gt;&lt;div id=hQ&gt;&lt;div id=hW&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;/body&gt;</code></p>
<p>etc</p>

CC BY-SA 4.0
2024-07-15T14:49:30.347Z
I've also provided a more programmatic manual disassembly example at: https://bitcoin.stackexchange.com/questions/117018/understanding-how-ordinals-work-with-the-bitcoin-blockchain-what-is-exactly-sto/123647#123647
Ciro Santilli OurBigBook.com
CC BY-SA 4.0
2023-05-10T19:38:18.307Z
2023-05-10T19:38:18.307Z
RedGrittyBrick
<p>Doom was <a href="https://ordinals.com/inscription/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0" rel="nofollow noreferrer">inscribed</a> on chain. The <a href="https://scriptpath.info/tx/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da" rel="nofollow noreferrer">reveal transaction</a> had the following script</p>
<pre><code>OP_PUSHBYTES_32 1809cc80b0c9bf0277e774f7f78c5dd0c61f9eda7bec7875dc99457bbf61af8f
OP_CHECKSIG
OP_0
OP_IF
OP_PUSHBYTES_3 6582895
OP_PUSHBYTES_1 1
OP_PUSHBYTES_23 746578742f68746d6c3b636861727365743d7574662d38
OP_0
OP_PUSHDATA2 520 3c21444f43545950452068746d6c3e3c68746d6c3e3c686561643e3c7469746c653e59657420416e6f74686572
...
OP_PUSHBYTES_73 682e73696e2c4b3d4d6174682e636f732c6b3d4d6174682e50492c71693d4d6174682e72616e646f6d2c573d4d6174682e6162732c45693d4d6174682e6d61783c2f7363726970743e
OP_ENDIF
</code></pre>
<p>Can someone provide an insight into the byte structure of the <a href="https://mempool.space/tx/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da" rel="nofollow noreferrer">raw witness data</a> (see picture below)? What's in the &quot;header&quot; <code>0e9713..d0</code>? Why are there two copies of hash <code>1809cc80..af8f</code>? Is there some online resource which could help me understand this better (besides bips)?</p>
<p><a href="https://i.sstatic.net/y5hSo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/y5hSo.png" alt="raw witness data" /></a>?</p>

<segregated-witness><taproot><ordinals>
Can someone explain the byte composition of an inscription reveal transaction?
DeLorean88
# Can someone explain the byte composition of an inscription reveal transaction?

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

Doom was [inscribed](https://ordinals.com/inscription/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0) on chain. The [reveal transaction](https://scriptpath.info/tx/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da) had the following script

```
OP_PUSHBYTES_32 1809cc80b0c9bf0277e774f7f78c5dd0c61f9eda7bec7875dc99457bbf61af8f
OP_CHECKSIG
OP_0
OP_IF
OP_PUSHBYTES_3 6582895
OP_PUSHBYTES_1 1
OP_PUSHBYTES_23 746578742f68746d6c3b636861727365743d7574662d38
OP_0
OP_PUSHDATA2 520 3c21444f43545950452068746d6c3e3c68746d6c3e3c686561643e3c7469746c653e59657420416e6f74686572
...
OP_PUSHBYTES_73 682e73696e2c4b3d4d6174682e636f732c6b3d4d6174682e50492c71693d4d6174682e72616e646f6d2c573d4d6174682e6162732c45693d4d6174682e6d61783c2f7363726970743e
OP_ENDIF

```

Can someone provide an insight into the byte structure of the [raw witness data](https://mempool.space/tx/521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da) (see picture below)? What's in the "header" `0e9713..d0`? Why are there two copies of hash `1809cc80..af8f`? Is there some online resource which could help me understand this better (besides bips)?

[![raw witness data](https://i.sstatic.net/y5hSo.png)](https://i.sstatic.net/y5hSo.png)?

**Tags:** segregated-witness, taproot, ordinals


---

## 2 answers

### Answer by username_1 on 2023-05-10. Score: 1 | Accepted answer

A taproot script path spend always has at least 2 witness items:

* The second-to-last item is the leaf script.
* The last item is the "control block" which consists of a leaf version, the taproot internal key (the public key before it was tweaked with the merkle root of the script tree) and optionally any merkle branches that prove the inclusion of the script in the tree. These are not present here because the tree only has one script (this might be required by the inscription standard, haven't checked).
* Any remaining items are used as the initial stack for script execution. In this case the single remaining item is the signature that satisfies the OP\_CHECKSIG opcode.

The public key `1809cc80..af8f` is used both as an internal key and in the script. This would normally hurt privacy because you reveal that the key path has the same key as the script path, but in the case of inscriptions it doesn't really matter because you already reveal you weren't going to use the key path, and it probably simplifies the code a little.


---

### Answer by username_2 on 2023-05-10. Score: 2

I think username_1 answered your main questions, I just wanted to point out how the inscribed data is encoded:

You wrote:

> ```
> OP_PUSHBYTES_32
> 1809cc80b0c9bf0277e774f7f78c5dd0c61f9eda7bec7875dc99457bbf61af8f
> OP_CHECKSIG 
> OP_0 
> OP_IF 
> OP_PUSHBYTES_3 6582895
>
> ```

Those three bytes are hex `6F7264` which is ASCII `ord` meaning the Ordinals project.

> ```
> OP_PUSHBYTES_1 1
> OP_PUSHBYTES_23 746578742f68746d6c3b636861727365743d7574662d38 
>
> ```

Those 23 bytes are `text/html;charset=utf-8` - the type of data inscribed

> ```
> OP_0
> OP_PUSHDATA2 520
> 3c21444f43545950452068746d6c3e3c68746d6c3e3c686561643e3c7469746c653e59657420416e6f74686572
>
> ```

Those 520 bytes are HTML (as indicated previously):

`<!DOCTYPE html><html><head><title>Yet Another Doom Clone</title></head><body><style>body{margin:0px;background:#000}#qQ{position:absolute;left:35vw;top:4em;font-size:2em;font-variant:small-caps;color:#aaa;animation:z 9s;}#cQ{height:100%;width:100%}#hQ{top:0px;width:10vw;height:2vh;border:3px solid #008;border-radius:3px;display:none}#fps{display:none}#hW{height:2vh;background:#00a}@keyframes q{50%{opacity:0}}.b{animation:q 1s linear infinite}@keyframes z{from{opacity:0}to{opacity:1}}</style><canvas id=cQ></canvas><Mdiv id=qQ><div id=hE>Yet Another Doom Clone<br><br><div class=b>Loading... <span id=jQ></span></div><br><br>Move: WASD<br>Aim/Shoot: Mouse/Click<br><br><br><br>By Nicholas Carlini</div><div id=hQ><div id=hW></div></div></div></body>`

etc

> **Comments:**
> **username_3**: I've also provided a more programmatic manual disassembly example at: https://bitcoin.stackexchange.com/questions/117018/understanding-how-ordinals-work-with-the-bitcoin-blockchain-what-is-exactly-sto/123647#123647  

---

