Anatomy of Bitcoin Transactions
By: Verified On Chain
Tags: Transactions, Pay To Public Key Hash, Blockchain, P2pkh, Bitcoin

In this post, we will deconstruct a Bitcoin transaction. A typical Bitcoin transaction is made up of inputs, outputs and a few other things, just like any other transfer. In Bitcoin, these senders and receivers are identified using addresses that can be viewed as bank account numbers. The difference between the bank account numbers and Bitcoin addresses is that the account numbers are integers, but Bitcoin addresses are hexadecimal numbers that cannot be linked to a person’s identity.

Let’s say Alice wants to send some Bitcoins to Bob; she would ask for Bob’s address. The addresses of Alice and Bob are as follows:

· Alice’s address- 18kwhcbb3J1rMkCcsbaVv1jJX5BdvqcCf5 (Base58 encoded)

· Alice’s address- 0055186DA52ACA9E8F0AC4B476AC447CD7704B13EB472047C4 (decoded)

· Bob’s address- 1BZmjFAHBmfexsY3dposiyD2vFGb3BZ4jm (Base58 encoded)

· Bob’s address — 0073E3E7ECED8184211684C98F367E7B6AF82F091868D3E9FC decoded)

(Note: Base58 encoding is a binary to text scheme which used to represent a large integer in the alphanumeric text)

As discussed earlier, a Bitcoin transaction contains inputs and outputs. In addition, it has version and lock time. Thus, a transaction looks like this:

· Version number

The version number is the current version of Bitcoin and the value stored in this field is 01000000, which is a hex representation of value 1. This value can change if there is a change in protocol in which the transactions are modified. If a miner node has a version 1 client, then he can only verify transaction of type version 1. The size of this field is 4 bytes.

(Note: The version number is stored using the little-endian format. Thus, the least significant number is stored at the least or first memory address. So, if we convert 01000000 number into a 32-bit integer, the value is equal to 1. If you want to learn about little endian click here)

· Lock time

Lock time is the date when this transaction becomes valid. It is generally set to 0, which means it is valid ASAP. If you set it to 0, the value stored in the field is 00000000. This field is also of 4 bytes.

· Inputs

In Bitcoin Blockchain, a transaction contains the input field, which[VK1] contains a reference to the past transactions. Here, there are only 2 ways of earning Bitcoin:

o Mining

If you are mining and add a Block to the Blockchain, you get a reward. This reward is called a Block reward. Block rewards are generated from thin air. There is a special type of transaction that called a Coinbase transaction, which the miner puts in the block while mining, where the miner assigns the block reward to themself.

o Sent by another user

The second way of getting Bitcoins is if someone sends some to you. So, when you want to spend some Bitcoin, you need to prove that you hold the Bitcoins that you are spending. This is done by referencing old transactions in which you got the Bitcoins and have them saved with you. For this example, let’s say, Dave sent 1.2 BTC to Alice. This transaction is unspent, so Alice will use it as an input to this transaction in which she is sending Bob 1 BTC. This input field contains 5 things:

a. Transaction hash of the previous transaction

b. Index for specifying which output of that transaction is been used

c. The length of the signature script

d. The signature script

e. Transaction sequence

a. Transaction hash of the previous transaction. The transaction is used as an identifier of the previous transaction. This field length is 32 bytes. This transaction is also called UTXO and is double hashed using SHA-256; the resultant is called transaction hash. Let’s say the previous transaction hash is 8190374a5a1feb54…..

b. Index for specifying which output of that transaction is been used. The previous transaction that has been used as an input in this transaction may contain multiple outputs. So, this field specifies the index number of the output, which is to be used as input.

c. The length of the following script. The script is the signature script used to verify the sender. This field is used to specify the length of it.

d. This is the signature script. It is generally 106 bytes long. Whenever a user sends a transaction, it contains a signature script which is run by the miner for verification. (Note: In our example, we have put the output of the script which is the opcode version of the script. The script is as follows:

<sig><pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG)

e. This field is irrelevant unless transaction lock time>0. Its value is generally FFFFFFFF.

Number of inputs

This field is used to tell how many inputs are used in the input field. A transaction can contain more than one UTXO. Because the transaction may not be enough, for example, if you want to send 6 BTC to someone and you 4 UTXO of 1.5 each. Here, the number of inputs will be 4 and you will have 4 transaction hashes and 4 indexes accordingly. In this example, we have only one 1 input. Thus, the transaction would look like as follows:

Multiple outputs

Just like inputs, there can be multiple outputs as well. Thus, if you are sending someone Bitcoins and the input value is greater than what are you sending, the change will be returned to your address. An output transaction will be created, which allows you to send the change to your address. Thus, in this case, you will have 2 outputs. Apart from the example given, you can have multiple receivers in a transaction as well. If you wish to send some Bitcoins to multiple people, you can do it in one transaction. The value of this field for this example will be 01.

Output

The output contains the receiver’s address and the amount of Bitcoins being transferred. It contains 3 fields.

o The amount to be transferred

o The length of the script

o The address script (Note: The pay-to-public-key-hash type of transaction, where the payment is done to the public key hash).

a. The output of Alice’s transaction will contain Bob’s address and the amount of Bitcoins being transferred, for example, 1 BTC. But, the unit used to transfer BTC is in Satoshi, were 1 Bitcoin = 100000000 Satoshi. So, when Alice is sending Bob 1 BTC, she is sending 100000000Satoshi. But, this value is stored in hexadecimal number in the field and the output will contain a hexadecimal form of 100000000 Satoshi, which is00E1F50500000000. The amount field is 16 bytes in length.

b. The length of the following script is generally of 25 bytes and its hexadecimal representation is 19.

c. This is the locking script. To spend the BTC sent by Alice, Bob should have the respective public key. When Bob tries to spend this UTXO, it will be verified if Bob holds the public key, which when hashed will give the same value as the UTXO script’s public key. This field is generally 25 bytes long. (Note: The picture contains the output of the script. This script is as follows: OP_DUP HASH160 <public key> OP_EQUALVERIFY OP_CHECKSIG)

This is what a Bitcoin transaction looks like. Now, go through this article again and make sure you have internalized the concepts.