Verifying blockchain transactions

We discussed proving ownership of bitcoins in the previous article. Let’s discuss how verifying transactions works at length in this article.

Remember that earlier we learned that the pubkey script has a few scripts in addition to the pubkey hash, which blockchain uses to verify the transaction? We will be using these scripts to verify transactions. Let’s see how.

But before that note that we use the pubkey script to verify the transaction that uses it as an input. In other words, to verify a transaction, we use the pubkey script of its inputs. In the example we saw in earlier articles, our transaction will be verified by the pubkey scripts that are output by the transactions that gave us the 0.75 bitcoin and the 0.4 bitcoin since we use them as inputs.

The Pubkey Script

A pubkey script consists of the following scripts:

1. OP_DUP
2. OP_HASH160
3. OP_EQUALVERIFY
4. OP_CHECKSIG

Each of these scripts performs a certain function during the verification process. Let’s see how this verification process works.

As we have already seen, the pubkey script also contains the pubkey hash. So, we can find the pubkey hash and the scripts in the following order in the pubkey script:

1. OP_DUP
2. OP_HASH160
3. <PUBKEY HASH>
4. OP_EQUALVERIFY
5. OP_CHECKSIG

Verification Process

In the first step of the verification process, we prefix the current transaction’s signature script—which contains the digital signature of the transaction and the transactor’s public key—to the pubkey script. So, we will have the following:

1. <Digital Signature>
2. <Public key>
3. OP_DUP
4. OP_HASH160
5. <PUBKEY HASH>
6. OP_EQUALVERIFY
7. OP_CHECKSIG

Then, we execute this script starting from the Digital Signature to the OP_CHECKSIG script. Since the first one in this script—digital signature—is just data, we push it into a stack. A stack is a data structure in which the item added first can only be removed last. To get a better intuition, think of a stack as a CD stack. The CD that you place first can only be removed last.

The public key is also just data and we push that into the stack as well on top of the digital signature. The stack now looks like this:

1. Public key
2. Digital Signature

Now, the third one in the script is OP_DUP, which is a script. This script duplicates the data at the top of the stack. Since it is the public key that is at the top of the stack, the script duplicates it. Now, our stack looks like follows:

1. Public key
2. Public key
3. Digital Signature

Obtaining the Pubkey Hashes

The next one in the script is OP_HASH160, which is again a script. This script hashes data at the top of the stack twice and pushes the hash into the stack after removing the original data. Since it is the public key that is at the top, the script pushes its hash. Now, the stack looks like this:

1. Pubkey hash
2. Public key
3. Digital Signature

The next one in the script is the Pubkey hash. Since that is data, we push it into the stack making the stack look like follows:

1. Pubkey hash (from the pubkey script)
2. Pubkey hash
3. Public key
4. Digital Signature

Verifying Ownership

The next one in the script is OP_EQUALVERFY, which is a script. This script consists of two scripts—OP_EQUAL and OP_VERFY. OP_EQUAL first checks if the two values at the top of the stack are equal. The two values at the top are the pubkey hashes.

But remember that the topmost pubkey hash comes from the pubkey script and we obtained the second one using the signature script of the transactor. So, the former is the hash of the public key of the account to which the transaction was sent and the latter is the public key of the current transactor.

So, what this OP_EQUAL script does is verify whether the initiator of the transaction was the one who received the money from the previous transaction. In other words, it has verified the ownership. If the two hashes are equal, then this script pops(removes) the two hashes and pushes the value 1. If the verification fails, then the script pops the two hashes and pushes the value 0. Let’s say the verification is successful. So, this is what the stack looks like now:

1. 1
2. Public key
3. Digital Signature

The OP_VERIFY script, then, checks the value at the top of the stack. If it is 0, then that means the bitcoins don’t belong to the sender, so the script terminates the verification process and transaction verification fails. If the value is 1, then it pops this value and continues with the rest of the process. Now, the stack looks like follows:

1. Public key
2. Digital Signature

Verifying the Signature

The next one in the script is the OP_CHECKSIG script. This checks the validity of the digital signature. The public key in the stack is the key from the transactor’s signature script. But the pubkey script has already verified that this public key is the same as the public key to which the previous transaction was sent using the OP_EQUALVERIFY script.

So, the OP_CHECKSIG script uses this public key to decrypt the digital signature. If the digital signature can be decrypted, then that means this has been encrypted using the transactor’s private key, which effectively authenticates the transactor. The decrypted data is the hash of the transaction. The transaction is then hashed twice to see if it matches the hash obtained by decrypting the digital signature. If they are the same, then that proves the transaction data is accurate.

Now, the transaction has been verified and the OP_CHECKSIG script pushes the value ‘true’ to the stack. If either the signature can’t be decrypted or the hashes don’t match, then the value ‘false’ is pushed into the stack. If the value at the top of the stack is not ‘false’, then the transaction is considered valid.

In this article, we saw how transaction verification takes place. In the next article, we shall see who carries out these verifications and how verified transactions are stored.