<blockquote>
<p>It sounds like this means that I could do an ordinal in a non-taproot address bitcoin transaction. So I could mint an ordinal with a P2PKH address.</p>
</blockquote>
<p>Historically output types with address standards came in two flavors: pubkeyhash-based (P2PKH, P2SH-P2WPKH, P2WPKH) and scripthash-based (P2SH, P2SH-P2WSH, P2WSH). P2TR outputs combine both these flavors by providing both a keypath and a scriptpath spending option. While it seems to me that a modification of the P2PKH output script to incorporate an envelope should be consensus valid, there are two things to note here:</p>
<ol>
<li>P2PKH addresses pertain <em>exactly</em> to the output script¹ template <code>OP_DUP OP_HASH160 &lt;pubkeyhash&gt; OP_EQUALVERIFY OP_CHECKSIG</code>. Modifying the P2PKH output script in the proposed manner results in a <em>bare script</em> output, because it no longer matches the P2PKH template.</li>
<li>The only bare scripts permitted in standard transactions are Pay to Pubkey (P2PK), Pay to Pubkey Hash (P2PKH), and bare multisig with up to three pubkeys.</li>
</ol>
<p>So at first glance, I would expect your experiment to result in a consensus-valid non-standard transaction. It would also be more expensive than using the P2TR-based envelope.</p>
<hr />
<p><sup>¹ in Bitcoin Core’s codebase an output script is also knows as  <code>scriptPubKey</code></sup></p>

CC BY-SA 4.0
2024-04-05T13:47:56.693Z
2024-04-25T13:56:48.950Z
2024-04-25T13:56:48.950Z
Murch
<p>I'm going to use ordinals as an example because they illustrate my question the most effectively. My understanding is that ordinals are created by writing opcodes into the transaction just like you would with a non-taproot transaction.  If I did a typical P2PKH transaction I would put</p>
<pre><code>&quot;scriptPubKey&quot;: &quot;OP_DUP OP_HASH160 HASH_OF_PUBKEY_IN_HEX OP_EQUALVERIFY OP_CHECKSIG&quot;
</code></pre>
<p>as my locking script, but If I wanted to do an ordinal I believe I would just make my locking script</p>
<pre><code>&quot;scriptPubKey&quot;: &quot;OP_DUP OP_HASH160 HASH_OF_PUBKEY_IN_HEX OP_EQUALVERIFY OP_CHECKSIG 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&quot;
</code></pre>
<p>It sounds like this means that I could do an ordinal in a non-taproot address bitcoin transaction. So I could mint an ordinal with a P2PKH address.</p>
<p>So what does tapscript actually do that P2PKH doesn't?</p>

<taproot><p2sh><p2tr><opcodes><ordinals>
How is tapscript different than P2PKH using opcodes from a developer perspective?
ChristianOConnor
# How is tapscript different than P2PKH using opcodes from a developer perspective?

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

I'm going to use ordinals as an example because they illustrate my question the most effectively. My understanding is that ordinals are created by writing opcodes into the transaction just like you would with a non-taproot transaction. If I did a typical P2PKH transaction I would put

```
"scriptPubKey": "OP_DUP OP_HASH160 HASH_OF_PUBKEY_IN_HEX OP_EQUALVERIFY OP_CHECKSIG"

```

as my locking script, but If I wanted to do an ordinal I believe I would just make my locking script

```
"scriptPubKey": "OP_DUP OP_HASH160 HASH_OF_PUBKEY_IN_HEX OP_EQUALVERIFY OP_CHECKSIG 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"

```

It sounds like this means that I could do an ordinal in a non-taproot address bitcoin transaction. So I could mint an ordinal with a P2PKH address.

So what does tapscript actually do that P2PKH doesn't?

**Tags:** taproot, p2sh, p2tr, opcodes, ordinals


---

## 1 answers

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

> It sounds like this means that I could do an ordinal in a non-taproot address bitcoin transaction. So I could mint an ordinal with a P2PKH address.

Historically output types with address standards came in two flavors: pubkeyhash-based (P2PKH, P2SH-P2WPKH, P2WPKH) and scripthash-based (P2SH, P2SH-P2WSH, P2WSH). P2TR outputs combine both these flavors by providing both a keypath and a scriptpath spending option. While it seems to me that a modification of the P2PKH output script to incorporate an envelope should be consensus valid, there are two things to note here:

1. P2PKH addresses pertain *exactly* to the output script¹ template `OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG`. Modifying the P2PKH output script in the proposed manner results in a *bare script* output, because it no longer matches the P2PKH template.
2. The only bare scripts permitted in standard transactions are Pay to Pubkey (P2PK), Pay to Pubkey Hash (P2PKH), and bare multisig with up to three pubkeys.

So at first glance, I would expect your experiment to result in a consensus-valid non-standard transaction. It would also be more expensive than using the P2TR-based envelope.

---

¹ in Bitcoin Core’s codebase an output script is also knows as `scriptPubKey`


---

