To understand Bitcoin scripts, we first need to talk about UTXOs (Unspent Transaction Outputs). Bitcoin can be broadly defined as a distributed ledger storing UTXOs.
We can think of a UTXO being made up of two important pieces of data:
Amount |
The value in Satoshis controlled by the UTXO. |
scriptPubKey |
A Bitcoin Script determining the conditions that must be met for the Amount to be spent. |
Bitcoin doesn't support accounts. It doesn't directly keep record of the BTC balance available to a given account. Instead an account's balance is fragmented into a number of UTXOs.
An account's balance is the total amount available for it to spend. If we had to look at all UTXOs on Bitcoin and determine which of these are spendable by a given account, we would effectively have the balance available to that account.
Bitcoin Scripts
A Bitcoin Script is a sequence of instructions, to be executed on a stack. A good range of opcodes are available for building these scripts. However, none of these allow for loops, rendering the language Turing incomplete.
All this means is that Bitcoin scripts provide a good level of programmability. However, it falls short of providing a complete range of instructions that would make it a smart contract platform.
This is considered to be a good limitation! Bitcoin was not intended to be a smart contract platform. Its focus is the exchange of the Bitcoin cryptocurrency and with over 10 years of history under its belt, this scripting solution has amply proven itself.
Spending UTXOs
So how do these scripts tie to the process of spending Bitcoins?
An account owner spends BTC by submitting a transaction identifying the UTXOs it intends to spend. However, this transaction can only succeed if it satisfies the condition set by each UTXO scriptPubKey. To meet this requirement, for each UTXO, the account owner includes an input script (the scriptSig).
A Bitcoin node, on processing a transaction, combines the scriptSig with the scriptPubKey and runs them together. If the result is successful and the transaction meets all other validation checks, the UTXO is spent creating new UTXOs reflecting the spending intentions of the account owner.
The process for spending a single UTXO is demonstrated below.
The Bitcoin Genesis
It's time to look at some scripts. To begin I will look at the very first Bitcoin block, the Genesis Block.
This block includes a single transaction with hash:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
This transaction is allocating a mining reward of 50 BTC. Such transactions are known as Coinbase transactions. Clicking on the transaction hash, at the bottom we can see the input and output scripts.
Note in this explorer:
scriptPubKey = Pkscript
scriptSig = Sigscript
Raw scriptSig:
04 ff ff 00 1d 01 04 45 54 68 65 20 54 69 6d 65 73 20 30 33 2f 4a 61 6e 2f 32
30 30 39 20 43 68 61 6e 63 65 6c 6c 6f 72 20 6f 6e 20 62 72 69 6e 6b 20 6f 66 20 73
65 63 6f 6e 64 20 62 61 69 6c 6f 75 74 20 66 6f 72 20 62 61 6e 6b 73
Raw scriptPubKey:
41 04 67 8a fd b0 fe 55 48 27 19 67 f1 a6 71 30 b7 10 5c d6 a8 28 e0 39 09 a6
79 62 e0 ea 1f 61 de b6 49 f6 bc 3f 4c ef 38 c4 f3 55 04 e5 1e c1 12 de 5c 38 4d f7
ba 0b 8d 57 8a 4c 70 2b 6b f1 1d 5f ac
Here the scriptSig isn't important. Remember the scriptSig is important when spending already existing UTXOs. In a Coinbase transaction we are creating new coins.
However, in this case, this scriptSig is interesting because of its message, which we can see by converting the last batch of hex bytes to ASCII.
scriptSig Breakdown:
Opcode: 04
|
Push next 4 bytes to the Stack |
Data: ff ff 00 1d
|
4 bytes of data |
Opcode: 01
|
Push Next 1 byte to the Stack |
Data: 04
|
1 byte of data |
Opcode: 45
|
Push next 69 bytes (45Hex) to the Stack |
Data: 54 68 65 20 54 69 6d 65 73 20 30
33 2f 4a 61 6e 2f 32 30 30 39 20 43 68
61 6e 63 65 6c 6c 6f 72 20 6f 6e 20 62
72 69 6e 6b 20 6f 66 20 73 65 63 6f 6e
64 20 62 61 69 6c 6f 75 74 20 66 6f 72
20 62 61 6e 6b 73
|
69 bytes of data
When converting these bytes to ASCII we get:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
|
The scriptPubKey is important since it provides us with the key for these 50 BTC to be spent by some subsequent transaction. Let's break it down:
Opcode: 41
|
Push next 65 bytes (41Hex) to the Stack |
Data: 04 67 8a fd b0 fe 55 48 27 19 67
f1 a6 71 30 b7 10 5c d6 a8 28 e0 39 09
a6 79 62 e0 ea 1f 61 de b6 49 f6 bc 3f
4c ef 38 c4 f3 55 04 e5 1e c1 12 de 5c
38 4d f7 ba 0b 8d 57 8a 4c 70 2b 6b f1
1d 5f
|
65 bytes of data
This is an uncompressed 65-byte public key.
|
Opcode: ac
|
OP_CHECKSIG
|
Thus, this script can be summarized as follows:
<public key>, OP_CHECKSIG
This is known as Pay-To-Pubkey (P2PK) script. Today, the use of P2PK has been replaced by P2PKH. However, the simple P2PK script is enough for us to understand the basics of Bitcoin Script processing.
The OP_CHECKSIG expects two values a digital signature and a public key. It verifies that the digital signature was indeed generated using the private key that pairs with the provided public key i.e. by the account designated to spend the UTXO.
Looking at this P2PK script we can see that this cannot be run as is! OP_CHECKSIG is only being supplied with a public key. For it to run someone must supply it the missing piece of the puzzle, the corresponding digital signature.
This is what the spending transaction has to do. Anyone wanting to spend such a UTXO, must provide a scriptSig containing the necessary digital signature.
The Genesis Coinbase we are looking at, isn't spent (and indeed cannot be spent). However, we can find other P2PK examples where both scriptSig and scriptPubKey are available.
Let's look at another historic transaction, the one between Satoshi Nakamoto and Hal Finney at Block 170 with hash f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16.
Here, under inputs we see both of these scripts. Just like the Genesis Coinbase the scriptPubKey is a P2PK script. This time we can see the scriptSig, which is providing the required digital signature. Let's break down the scriptSig:
Opcode: 47
|
Push next 71 bytes (47Hex) to the Stack |
Data: 30 44 02 20 4e 45 e1 69 32 b8 af
51 49 61 a1 d3 a1 a2 5f df 3f 4f 77 32
e9 d6 24 c6 c6 15 48 ab 5f b8 cd 41 02
20 18 15 22 ec 8e ca 07 de 48 60 a4 ac
dd 12 90 9d 83 1c c5 6c bb ac 46 22 08
22 21 a8 76 8d 1d 09 01
|
71 bytes of data
The raw digital signature.
|
Once the two scripts are joined, we end up with:
<digital signature>, <public key>, OP_CHECKSIG
OP_CHECKSIG is now ready to run and verify if the UTXO can be spent!
Concluding Remarks
Today we looked at two simple Bitcoin scripts. We saw how the two scripts work together to only allow a specific account owner to spend the UTXO.
Today more powerful scripts are in use. P2PK has been replaced by P2PKH primarily because of the way it exposes the public key for everyone to see.
Private/public key pairs and digital signatures are the products of the Elliptic Curve Digital Signature Algorithm (ECDSA). Today breaking ECDSA is considered to be impractical. Breaking here means being able to discover the private key given the public key.
However, advancements in technology, especially in Quantum Computing, is raising fears that breaking ECDSA will happen in the future. This would expose all unspent UTXOs using P2PK to the possibility of being spent by whoever manages to break the public key first.
Reference
Bitcoin Script Opcodes
Bitcoin Genesis Block
Satoshi Nakamoto to Hal Finney