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.
