<p>The first output types you list are <em>bare scripts</em>, in which the output script and input script are actually provided in verbatim and executed literally.</p>
<p>The other output types you mention are examples of <em>standard output types</em> that follow essentially a type of shorthand for a longer script. A specific output script pattern has been defined to be treated according to some fixed rules. The specific rules for these output types are part of the Bitcoin consensus rules.</p>
<p>However, there are other types of outputs that you have not mentioned here that permit the recipient to define arbitrary scripts for their validation, e.g. <em>P2SH</em>, <em>P2SH-P2WSH</em>, <em>P2WSH</em>, and <em>P2TR</em>. When these output types are used in that manner the executed script to determine validity of an input (i.e. <em>Redeem Script</em>, <em>Witness Script</em>, or <em>Leaf Script</em>) may contain arbitrary <em>Script</em> instructions.</p>

CC BY-SA 4.0
2023-12-29T21:19:58.403Z
2023-12-29T21:19:58.403Z
Murch
<p>When I first started learning how transaction are validated, it made sense why a script language was needed: the scriptPubKey was executed along the scriptSig, the software just executes this &quot;blindly&quot;, following the rules of what each Op_code does.</p>
<p>This is the way the first transaction types (P2PK and P2PKH) are actually validated, and this is how I thought all transactions were validated: you have a script language with which you can create all sorts of exotic spending conditions, and the software just executes the scriptPubKeypt alongside the scriptSig to see if the transaction is valid. It's simple and it makes sense.</p>
<p>But now enter P2SH transactions. It took me a long time to get that now, the script is not actually blindly validated by the software anymore. We actually tell the software what it is supposed to do when it encounters such a transactions: it has to verify the locking script provided corresponds with the hash in the scriptPubKey, and then verify the scriptSig with the locking script.</p>
<p>The same is true with Segwit transactions. Here the scriptPubKey is nothing more than a push data of a hashed public key. We have to explicitly tell the software what to do, how to handle such transactions. There's not even a checksig anymore in the scriptPubKey, or any Op_code at all for that matter, in the scriptPubKey or in the witness.</p>
<p>This all seems less &quot;natural&quot; and organic than the previous way of verifying transactions, that is the software blindly running the scriptPubKey and the scriptSig.</p>
<p>And after all this I wonder what is even the point of having a script language at all, if we actually have to explictly tell the software how to handle each transaction type?</p>
<p>To be clear, I'm not for or against anything in particular, I'm just interested in the topic and trying to learn.</p>

<transactions><script><transaction-verification>
What is the point of having a script language now?
mathboi
# What is the point of having a script language now?

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

When I first started learning how transaction are validated, it made sense why a script language was needed: the scriptPubKey was executed along the scriptSig, the software just executes this "blindly", following the rules of what each Op\_code does.

This is the way the first transaction types (P2PK and P2PKH) are actually validated, and this is how I thought all transactions were validated: you have a script language with which you can create all sorts of exotic spending conditions, and the software just executes the scriptPubKeypt alongside the scriptSig to see if the transaction is valid. It's simple and it makes sense.

But now enter P2SH transactions. It took me a long time to get that now, the script is not actually blindly validated by the software anymore. We actually tell the software what it is supposed to do when it encounters such a transactions: it has to verify the locking script provided corresponds with the hash in the scriptPubKey, and then verify the scriptSig with the locking script.

The same is true with Segwit transactions. Here the scriptPubKey is nothing more than a push data of a hashed public key. We have to explicitly tell the software what to do, how to handle such transactions. There's not even a checksig anymore in the scriptPubKey, or any Op\_code at all for that matter, in the scriptPubKey or in the witness.

This all seems less "natural" and organic than the previous way of verifying transactions, that is the software blindly running the scriptPubKey and the scriptSig.

And after all this I wonder what is even the point of having a script language at all, if we actually have to explictly tell the software how to handle each transaction type?

To be clear, I'm not for or against anything in particular, I'm just interested in the topic and trying to learn.

**Tags:** transactions, script, transaction-verification


---

## 1 answers

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

The first output types you list are *bare scripts*, in which the output script and input script are actually provided in verbatim and executed literally.

The other output types you mention are examples of *standard output types* that follow essentially a type of shorthand for a longer script. A specific output script pattern has been defined to be treated according to some fixed rules. The specific rules for these output types are part of the Bitcoin consensus rules.

However, there are other types of outputs that you have not mentioned here that permit the recipient to define arbitrary scripts for their validation, e.g. *P2SH*, *P2SH-P2WSH*, *P2WSH*, and *P2TR*. When these output types are used in that manner the executed script to determine validity of an input (i.e. *Redeem Script*, *Witness Script*, or *Leaf Script*) may contain arbitrary *Script* instructions.


---

