The Data Elements

Now that we understand what a Merkle tree is and why they are used in a number of distributed and peer-to-peer systems, let us take a closer look at their role in bitcoin in particular.

Bitcoin is a peer-to-peer electronic cash system. When creating physical cash, there are substantial measures taken to ensure the authenticity of the cash instrument; however even with these measures, there is still a significant problem with the counterfeiting of these physical objects. Creating an electronic cash system needs similarly sophisticated techniques to ensure the integrity of the cash-like objects of the system.

The use of Merkle trees as a verification process is one of the techniques employed to verify the authenticity and integrity of these cash-like objects on the Bitcoin network (referred to as satoshis). For this system to have any merit, these tokens must be verified from their issuance through each of the instances where they are used to exchange value in the system. In the case of Bitcoin, these exchange events are referred to as transactions.

When a Bitcoin transaction occurs, it is generated by the wallet software as a set of statements in Bitcoin's native programming language called 'Script'. At the very least, a transaction will be a statement that provides a 'true' solution for a locking puzzle that was generated by the previous custodian when the bitcoin tokens were received, as well as a statement for the generation of a new locking puzzle that will be passed on to the next entity in the chain of custody of the tokens. The former are referred to as inputs for a transaction and the latter as outputs.

These locking and unlocking scripts often utilise digital signatures (which can be learnt about here in our course on digital signatures) with asymmetric public and private keys that are generated by the wallet software via an elliptic curve digital signature algorithm (ECDSA). These digital signatures may sound complex, but they are simply an electronic, encrypted, stamp of authentication on digital information such as email messages, macros, or electronic documents. In the case of Bitcoin, these keys are used to create a solution to the locking puzzle that contains the tokens received via an earlier transaction so that they may be spent. The below diagram shows the most commonly used Bitcoin script template called a Pay to Public Key Hash or P2PKH. Here, not only is a hash of the transaction preimage used to create the signature, but the public key itself is hashed to keep it private until the coin is spent.

These script statements instruct operations on chunks of data which represent the values for the specific input fields of the statement inside the <> in the image above. These chunks are concatenated into a string of raw transaction data which can be seen in the table below. Since a Bitcoin transaction will only be validated if it is the first time the inputs specified in the transaction statements are being spent, each transaction has unique raw data. When this raw transaction data is put through a hash function, a unique hash is generated. In this way, each transaction can be identified by this hash value (TXID) rather than having to specify all the details of the transaction.

Bytes	Data Field	Hexadecimal String
4	Version	01000000
1-9	Number of Inputs	01
32	Previous TX hash (reversed)	f253cf794a7a0aff45144c8ea1fc4271be683952ae8241ee1524266b46375246	Inputs
4	Previous Output Index	00000000
<in-counter> qty with variable length per input	Script Length	6b
<in-script length>-many bytes	ScriptSig (Unlocking Script)	4830450221008f8c069a2e8aa0cce2455374916ff1dedc40da58680c7fab925b0d8206e d4e48022013bd576c0ed17448525d282ca4ddc55245c788da88eee7e35a2084b7bed78 caa01210302e3a61057a9c9616291b17085c16d9e1f22821395e3ba792f4492f61d57169b
4	nSequence	ffffffff
1-9	Number of Outputs	01
8	Value (reversed)	30c11d00000000	Outputs
1 - 9 bytes VI = VarInt	Script Length	19
<out-script length>-many bytes	ScriptPubKey (Locking Script)	76a914800311626c5e50a10ea7d84f42471c0e7c17a4a088ac
4	nLockTime	00000000
Serialised String of Raw Transaction Data
0100000001f253cf794a7a0aff45144c8ea1fc4271be683952ae8241ee1524266b46375246000000006b4830450221008f8c069a2e8aa0cce2455374916ff1d edc40da58680c7fab925b0d8206ed4e48022013bd576c0ed17448525d282ca4ddc55245c788da88eee7e35a2084b7bed78caa01210302e3a61057a9c96162 91b17085c16d9e1f22821395e3ba792f4492f61d57169bffffffff0130c11d00000000001976a914800311626c5e50a10ea7d84f42471c0e7c17a4a088ac00000000