Transactions – Why have a scripting language now?

When I first started learning how transactions are verified, I understood why I needed a scripting language. scriptPubKey was executed along with scriptSig, and the software executes it “blindly” according to the rules that each Op_code follows.

I believe this is how the first transaction types (P2PK and P2PKH) are actually verified and how all transactions are verified. There is a scripting language that allows you to create all kinds of exotic spending conditions, and then the software runs. Use scriptPubKeypt with scriptSig to check if the transaction is valid. It’s simple and makes sense.

But now enter your P2SH transaction. Now it took me a long time to get it. Scripts are actually no longer blindly verified by software. We actually tell the software what to do when such a transaction occurs. You need to check if the provided locking script matches the hash of scriptPubKey and then check scriptSig with the locking script.

The same goes for Segwit transactions. Here scriptPubKey is just the push data of the hashed public key. We need to explicitly tell the software what to do and how to process those transactions. There is no more checksig in scriptPubKey or watcher than Op_code or at all for that matter.

All of this seems less “natural” and organic compared to the previous way of verifying transactions, i.e. software blindly running scriptPubKey and scriptSig.

And in the end, I wonder what’s the point of having a scripting language if we have to explicitly tell the software how to handle each transaction type.

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