satoshi created bitcoin script which is the language that the bitcoin client uses to handle most of the operations such as sending or verifying transactions.
was it necessary to have another language for these operations? isn't it possible to write the whole runtime in one language?
was it necessary to have another language for these operations? isn't it possible to write the whole runtime in one language?
To be clear: the goal of the scripting language isn't for defining the runtime logic of blockchain validation. No part of Bitcoin Core itself is written in the Bitcoin Script language, just in C++. The goal of the Bitcoin Script language is for customizing the conditions under which transaction outputs can be spent. These scripts are intended to be written by "users" of the system, not by (authors of) the system itself. Of course, in practice they are written and designed by the authors of the wallet software these users use, but it permits a flexibility that wouldn't otherwise exist: wallet authors can develop and experiment with new scripts permitted by the language, without needing to wait for the entire Bitcoin ecosystem to adopt changes to specifically enable their use case.
Would it be possible to not have such a language: certainly. There are several cryptocurrencies that don't have such a concept at all. But this alternative doesn't need to mean that the Script language is replaced by C++ (or whatever other language the validation logic is written in) - it can simply mean there is no customizability of spending conditions at all, and every output is just e.g. a public key, and every input is just a signature, and nothing else is possible.
Having this language at all just introduces features that wouldn't be achievable through other means. The simplest example is having coins that can only be spent when multiple people sign off on it(*), or only after a certain amount of time, or after some secret gets revealed. Together these are the basis for example for trustless escrows (where the escrow can't steal the coins), or for systems built on top like payment channels.
Perhaps your question is: why is this customizability of spending conditions not done using the language as the one the validation logic is written in? There are several reasons for this:
(*) There are techniques in modern cryptography to actually make a single public key that can only be spent when multiple people cooperate to spend it.
It is theoretically possible that Satoshi could have taken the entire C++ language (Bitcoin Core is written in C++) and then severely restricted what C++ functionality was available for Bitcoin scripting. Ethereum did something similar by making modifications to Javascript and calling it Solidity. An alternative approach that other altcoins took (e.g. Mimblewimble based altcoins such as Grin, Beam) was not to have a scripting language at all and only allow single signature spends (no multisignature, no timelocks etc).
As RedGrittyBrick says for various reasons it made sense to start from a much more limited language (Forth) than C++ as even Forth was too expressive for Bitcoin Script; various Forth opcodes had to be disabled for Satoshi to be comfortable it wasn't exposing Bitcoin to uncertain verification costs. (There are also new opcodes that Bitcoin Script would like that aren't in Forth.)
Taking an existing language (C++, Javascript, Forth etc) and then removing and adding functionality so it can be used for Bitcoin scripting is an imperfect approach. Simplicity is an effort to build a scripting language for Bitcoin from the ground up. It is still a work in progress and would need a soft fork to be added to Bitcoin but designing specifically for the Bitcoin scripting use case and providing guarantees that aren't available in adjusted existing languages seems to be a much more promising approach.
Consider a script that says
While (true) {
// some pointless but slow calculation
}
in order to discover if the transaction containing it is valid, every node on the network has to run this until it returns a value.
The halting problem means that it is impossible to know whether a script will ever complete.
These scripts are created by the transaction creators and could contain any script that a malicious person can dream up.
One way to combat malicious scripts is to have nodes know of a small number of standard scripts and not relay non standard scripts.
You could ask, if we only have a few standard transaction types, we don't need a scripting language at all, the evaluations could be hard coded in C++ and no scripts would be in the transaction itself. This would not be Bitcoin. Having a scripting language arguably provides for future flexibility.
We need the scripting language to be judiciously limited, so that we can be sure any script can be executed in finite time. we also need to be certain that no matter what malicious data is presented to the script by bad actors, it will terminate in finite time. having the scripting language be a carefully designed minimalistic language with limited capabilities arguably provides the best assurance of this.
As Crypto News said
the limitations in Bitcoin Script prevents a “logic bomb,” or an infinite loop from being included in any single transaction. This restriction eliminates the possibility of a denial-of-service (DoS) attack on the network.
See also
