Uncovering the secrets of blockchain technology (V): Deep understanding of Bitcoin transaction scripts

The author of this article is Liao Xuefeng, a technical expert at Huobi Blockchain Research Center. He has ten years of experience in software development and is proficient in programming languages ​​such as Java/Python/Ruby/Visual Basic/Objective C/Lisp. He has in-depth research on open source frameworks and is the author of the book "Spring 2.0 Core Technology and Best Practices". He also has multiple amateur open source projects hosted on GitHub.

This article introduces the relevant knowledge of Bitcoin and Bitcoin blockchain in detail.

In the Bitcoin blockchain, each block points to the previous block, and these block hash chains calculated by SHA256 are the basis for the Bitcoin ledger to be tamper-proof.

In a block, the Bitcoin system uses a transaction to represent a Bitcoin transaction. A block contains at least one transaction. The hashes of these transactions are calculated through the Merkle Tree to calculate the Merkle Hash of all transactions and included in the block Hash, thereby achieving the immutability of the transaction.

If we look closely at each transaction, we can find that, except for the first transaction which is the mining proceeds of the miner, each transaction has one or more inputs (TxIn) and one or more outputs (TxOut):

The first income transaction mined by a miner is usually called a Coinbase. It has no input, so the hash of TxIn is always marked as 00000000…0000

For other transactions, any TxIn can be uniquely traced back to a transaction Hash and index before this block on the blockchain:

Through the transaction hash and index (starting from 0), an unspent transaction output, UTXO (Unspent Transaction Output), can be uniquely determined. In this way, each Tx Input is associated with a previous Tx Output.

We assume that in the previous transaction, Bob paid Alice 0.15 BTC.
Since Bitcoin does not have the concept of accounts, the output of this transaction does not include Alice’s name or public key.

So, if Alice wants to spend this 0.15 BTC, how should she prove that she owns this UTXO and that others cannot impersonate Alice to spend this UTXO?
The answer is that the output created by a Bitcoin transaction is not actually a simple public key address, but a script. In the transaction where Bob pays Alice 0.15 BTC, the output script created by Bob is similar to:

OP_DUP OP_HASH160 abcd1234…9876 OP_EQUALVERIFY OP_CHECKSIG

Among them, abcd1234…9876 is Alice’s public key Hash. The meaning of the entire script is that whoever can provide a signature and a public key to run this script can spend the 1.5 BTC of this transaction.

Since only Alice's private key can be used to create a signature, a signature created with a private key other than Alice's will not be able to pass the verification of this script, so others cannot impersonate Alice to spend this output.

Once Alice provides a signature and her own public key, she has actually created another transaction to spend this output.

Everyone can verify whether the new transaction created by Alice is valid. If it is valid, the transaction will be packaged into a new block by the miners and become an unchangeable part of the blockchain.

Let’s take the famous Pizza Transaction as an example to verify whether a transaction is valid.

In transaction cca75078…4d79, the only TxIn input provided sigScript is:

8b4830450221009908144ca6539e09512b9295c8 a27050d478fbb96f8addbc3d075544dc41328702

201aa528be2b907d316d2da068dd9eb1e23243d9 7e444d59290d2fddf25269ee0e0141042e930f39

ba62c6534ee98ed20ca98959d34aa9e057cda01c fd422c6bab3667b76426529382c23f42b9b08d78

32d4fee1d6b437a8526e59667ce9c4e9dcebcabb

The sigScript actually consists of two parts:

Signature : 30450221…ee0e01 (71 bytes + 1 byte signature type). The actual signature is 30450221…ee0e without the last byte 01. The signature type is SIGHASH_ALL (0×01).
Public key : 042e930f…cabb (65 bytes)

To verify that the transaction is valid, we first need to find the output of the previous transaction based on the Previous Output Hash declared in TxIn: a1075db5…d48d and index 0:

https://webbtc.com/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d

The script output of this transaction is:

1976a91446af3fb481837fadbb421727f9959c2d32a3682988ac

The Bitcoin script consists of a series of instructions and data, each instruction occupies one byte, and the data is determined by the length of the data header. The Bitcoin instructions after the above binary script is translated are as follows:

OP_DUP OP_HASH160 46af3fb481837fadbb421727f9959c2d32a36829 OP_EQUALVERIFY OP_CHECKSIG

Now, we have the signature, the public key, and the script:

sig: 30450221…ee0e01
pubkey: 042e930f…cabb OP_DUP OP_HASH160 46af3fb4…6829 OP_EQUALVERIFY OP_CHECKSIG

You can run this script to verify that the transaction is valid.

Bitcoin script is designed as a virtual machine instruction that runs on a stack. It has only a limited number of instructions and is intentionally designed without loops or conditional jumps. Therefore, Bitcoin script is not a Turing-complete language.

The execution of Bitcoin script is very simple. We first need to prepare an empty stack, and then push the signature and public key into the stack:

Next, we can execute the TxOut script:

OP_DUP OP_HASH160 46af3fb481837fadbb421727f9959c2d32a36829 OP_EQUALVERIFY OP_CHECKSIG

First, OP_DUP is executed. This instruction copies the element at the top of the stack, so the result becomes:

Next, OP_HASH160 is executed, which calculates SHA256/RipeMD160 on the top element of the stack, which actually calculates the public key Hash, so the running result becomes:

The next instruction is actually a piece of data, and we push the data directly into the stack:

Then, execute OP_EQUALVERIFY. This instruction will compare whether the two elements at the top of the stack are equal. If they are not equal, the entire script will fail to execute. If they are equal, the script will continue to execute, so the running result becomes:

Finally, execute the instruction OP_CHECKSIG, which verifies the signature. First, we verify the entire transaction based on the signature type SIGHASH_ALL (0×01). The verification method is:

Remove the scriptSig of all TxIns of the current Transaction (the red part), replace the scriptSig of the current TxIn with the script of UTXO (the blue part), and adjust the length field (the green part):

Finally, add the little-endian 4-byte signature type 0×01 (gray part) and calculate SHA256 twice, we get:

c2d48f45…2669

Now, use the ECDSA algorithm to verify the signature:

boolean ecdsa_verify_signature(byte[] message, byte[] signature, byte[] pubkey)

Based on the verification result of the signature, we can confirm whether the transaction is valid.

Since the script was introduced, we can see that Bitcoin actually implements a digital currency ownership transfer mechanism that is strictly based on computer program verification through programming scripts. Due to the scalability of computer programs, Bitcoin payments are not limited to being paid to a certain public key address. Using scripts, we can construct various payment conditions, such as multi-signature verification conditions:

2 3 OP_CHECKMULTISIGN

This multi-signature script that provides multiple public key addresses and requires multiple signature verifications allows at least N signatures to be given out of M signatures. The above script allows any two valid signatures from the three public key addresses to be provided.

When we host Bitcoin in a third-party online wallet, we can use multi-signature to ensure that the output can only be used after the signature of ourselves and the third-party wallet. This ensures that hackers cannot spend the user's Bitcoin after attacking the third-party wallet.

Through OP_CHECKLOCKTIMEVERIFY, we can specify a lock time for a transaction, before which the transaction output cannot be spent. This instruction actually implements the function of Alipay locking funds for 7 days before paying to the seller.

There are also some transactions that do not specify a public key hash. For example, the script of this transaction is as follows:

OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL

It means that whoever can provide a data whose SHA256 is 6fe28c0a…0000 can spend the transaction.
(Note: This transaction has been spent, someone found the data that meets the conditions)

From the Bitcoin script, we can see that blockchain-based digital currency payment is actually a secure transfer of digital currency ownership. If we register financial assets or physical assets in a digital form on the blockchain, we can safely transfer ownership under various conditions through scripts. This is exactly the application of smart contracts on the blockchain.