In this post we're going to talk about what the Bitcoin scripting language and Bitcoin scripts. We will also see why a script is used in the transaction output instead of a single public key.
Bitcoin scripting language
The Bitcoin scripting language is built specifically for Bitcoin. It is probably inspired by an old stack-based simple programming language. But it is not necessary to understand Forth in order to use Bitcoin Scripring language.
The main properties of this language are:
stack-based: it is based on a stack. There are no variables, no conditional statements. So all the operations are always executed exactly once in linear manner. In particular operations are applied to the member on the top of the stack following the schema FIFO (First in First Out).
non Turing complete: it is not possible to compute arbitrarily powerful functions. In fact, there are no conditional statements and no loops. So just looking at a script, it is possible to understand how long it might take based on the number of instructions. This because the miners have to run the scripts submitted by users directly in the transactions. So they must not have the ability to submit scripts that might have an infinite loop and might run forever. The Bitcoin script will always run in a finite numbers of steps corresponding to the number of instructions that it cointains.
with two types of instructions: data instructions and OP_CODE. The data instruction are simply containing some value and are surrounded by angular brackets (i.e. <data>). The OP_CODE are specific operations belonging to Bitcoin Scripting language that acts on the value on the top of the stack and put their result also on the top of the stack.
Common OP instructions
The most common OP instructions are the following:
OP_DUP: duplicates the data on the top of the stack
OP_HASH160: computes the hash of the data on the top of the stack and replace it with the result
OP_EQUALVERIFY: verifies if the first two data on the top of the stack are equals. If so, these two data are removed
OP_CHECKSGN: controls the digital signature using the public key and returns true or false whether the signature verifies or not
The most common script: transaction validation
Let's take as an example the most common script in Bitcoin: the one used to redeem a transaction. This script is formed concatenating the scriptSig in the transaction input, with the scriptPubKey in the transaction output.
When a transaction has to be validated, the two scripts get concatenated together. This script checks the reference to the previous transaction to see if it can be used to transfer the money of the current transaction. If the resulting script runs without any errors, the transaction is considered valid.
The first two instructions in this script are simply data instructions:
the signature of the sender
the public key used to generate that signature
This data are just pushed on the stack without doing any operations. Now we will start using the OP instructions to act on these data:
OP_DUP: we duplicate the public key on top of the stack
OP_HASH160: computes the cryptographic hash of the public key and puts it on the top of the stack
Now there's a new value pushed onto the stack:
the hash of the public key specified by the sender
There the last two operations are applied:
OP_EQUALVERIFY: verifies if the two hashes on the top of the stack are equals. If so they are removed. If not, an error is returned and the transaction is not valid.
OP_CHECKSIG: now we have the public key and the signature left on the stack. This last operation checks if the public key corresponds to the signature, so if the signature is valid. It returns true if the signature is valid, false otherwise.
Script Properties
The main properties of Bitcoin language and scripts are the following:
every Bitcoin script can only produce two outcomes. It can either execute successfully or return an error. In the Transaction validation, if there's any error while the script is executing, the whole transaction will be invalid and shouldn't be accepted into the blockchain
Bitcoin scripting language is very small, there's only room for 256 instructions, since each one is given by one byte. 15 of them are currently disabled and 75 are reserved, so actually they don't have any meaning and could be assigned later on.
Bitcoin scripting language includes instructions to manage basic arithmetic, basic logic, throwing errors and cryptography management such as hash functions, signature verification.
More Sophisticated Bitcoin Scripts
Checking Multiple Signatures
With Bitcoin Scripting language it is possible to check mupliple signatures with one instruction: CHECKMULTISIG. In this case it is necessary to specify n public keys and a threshold t. This instruction will execute without errors if there are at least t valid signatures belonging to these n public keys.
There's a small bug regarding this instruction: it pops an extra data value off the stack and ignores it. So, in programming, it is necessary to deal with it putting an extra dummy variable onto the stack. It is considered a feature of Bitcoin language, because it is there since the beginning of times and the costs of removing it are much higher than the damage it causes.
Proof-of-burn
Proof-of-burn is actually a script that can never be redeemed. If you have a proof-of-burn, it's provable that those coins have been destroyed, there's no possible way for them to be spent. To implement a proof-of-burn it's necessary to insert an OP_RETURN instruction, which throws as soon as it is reached, no matter what instructions preeceded it. The data that comes after OP_RETURN are ignored, so this is an opportunity to specify arbitrary data in a script that will remain in the blockchain.
This kind of script has mainly two purposes:
insert arbitrary data into blockchain, for example timespamp a document and proove that you knew some data at a specific time. In this case it is possibile to create a very low value Bitcoin transaction that's proof-of-burn. So you can destroy a very small amount of currency, and in exchange write something into the blockchain, which should be kept forever.
some alternate coins systems, can promote their new currencies forcing people to destroy Bitcoin in order to gain coins in the new system. We will see more about this in future lectures.
Pay-to-script-hash
To use Bitcoin a sender must specify a script exactly. A common consumer, wouldn't be able to specify it, if for example he is ordering something online and a MULTISIG script is required. As a consumer, he just want to send the money using a simple address. In response to that problem, there's a feature in Bitcoin that lets the sender specify just a hash of the script that is needed to redeem the coins. The script acts as follows:
The sender specifies the hash of the script and it is put on the top of the stack
The receiver specifies as a data value, the value of the script corresponding to the previous hash
The alorithm checks if the hash of this data corresponds to the one specified by the sender
If the two hashes match, the top data value from the stack is reinterpreted as instructions, so it's executed a second time as a script.
This pay-to-script-hash is an alternative to make Bitcoin payments to the standard way, which is called pay-to-public-key. This is a useful feature that was not available in the first version of the protocol. It removes complexity from the sender, and has an additional efficiency gain since the output scripts are as small as possible with pay-to-script-hash: they just specify a hash, and all of the complexity is pushed to the input scripts.
Custom script
There isn't too much creativity in terms of what scripts people actually use. One reason for that is that Bitcoin nodes have a white list of scripts and they refuse to accept scripts that they consider not standard. This doesn't mean that those scripts can't be used at all, it just makes them harder to use, we will talk more about it later.
Blockchain & Cryptocurrency #13: Bitcoin Scripting Language | Ecency
