The locking script on an UTXO and the unlocking script are written in bitcoin scripting language. When a transaction is validated, the unlocking script in each input is executed alongside the corresponding locking script to see if it satisfies the spending condition. Can someone explain the nitty gritty of Bitcoin script with locking and unlocking script?
Wasn't completely sure what you wanted to know as there is a lot of information regarding Script. I've added a preliminary answer and a link to the official documentation. Hope that helps!– timothyylimMay 15, 2018 at 6:06
Same here, not completely sure so I've tried to make it as complete as possible.– sr_giMay 15, 2018 at 8:53
There are quite a lot of things going on there, so let's break it down bit by bit.
A transaction can be seen as a collection of inputs and outputs. Inputs refer to previously created UTXOs, while outputs generate new ones. Therefore, when creating a transaction each input spends a UTXO and each outputs creates one.
Outputs is what contains the so called locking script, or how it is normally referred in a transaction, the
scriptPubKey. Such an script contains the condition required to spend such a UTXO.
Inputs contain references to previously created UTXOs (through the
prev_out_index fields). Moreover, inputs contain the so called unlocking scripts, or how they are normally referred,
scriptSig. Such scripts require the proof of fulfilment of the conditions specified in the UTXO each input is trying to redeem.
The most commonly used transactions in Bitcoin, and therefore the most common example of this, are Pay-to-PubKey-Hash (P2PKH) transactions, or transactions that pay to a Bitcoin address. A script "paying to a Bitcoin address" will require that you can proof to be the "owner" of such an address. Let's see how this works:
A transaction creating a P2PKH UTXO will have a
scriptPubKey looking as follows:
ScriptPubKey = OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG
Whereas a transaction tying to redeem such an UTXO as an input, will have a
scriptSig looking as follows:
ScriptSig = <sig> <pubKey>
If we put both scripts together in a stack, like Bitcoin does, what we get is the following script:
<sig> <pubKey> OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG
In order to analyze the script you should have two things in mind. There are two types of clauses, opcodes and data (represented between
< >). Moreover, scripts are read left to right, and data is used as input to opcodes.
The execution of the script will first duplicate the public key (since is the first operation of the script), and compute the
hash160 of it. Then it will check if the computed hash160 matches with the one provided in the UTXO the input is trying to redeem, and finally it will use the remaining public key (recall that we have duplicated it) and the signature to check the correctness of the signature.
You can find more info about the validation of P2PKH in the Bitcoin dev guide. Moreover, there are several other examples of this. You can find the standard types of transactions also in the dev guide. An extensive list of Bitcoin Script opcodes can be found in the Bitcoin wiki.
There isn't a difference between a 'locking script' and an 'unlocking script'. A script is simply a set of instructions that specifies how a UTXO is able to be spent, this locks or encumbers (to use the official terminology) the future spending of the bitcoin. Unlocking the bitcoin requires satisfying the script.
The simplest transaction contains a script which asks for
- a public key that, when hashed, yields destination address D embedded in the script, and
- a signature to prove ownership of the private key corresponding to the public key just provided.
You can encumber a UTXO with more complex requirements such using the OPCODE 'OP_CHECKLOCKTIMEVERIFY' which doesn't allow the bitcoin to be spent until a point in the future.
You can read more about Script here: