The Bitcoin block header contains important information inside the block. These are divided into 6 fields which provide details of the block summary. Aside from the block header, there are the transactions and the coinbase field which are separate parts of the block. Each block header is unique and cryptographically secured, which is what gives it the property of immutability.
The block headers are serialized with a total length of 80 bytes. It is then hashed as part of the Proof-of-Work (PoW) consensus algorithm that is used when mining for Bitcoin. During that process, the serialized header becomes part of the consensus rules which miners must follow as part of the consensus mechanism. The miners are full nodes who participate in the consensus protocol in which blocks are validated and in return the miner who validates the block receives a reward in Bitcoin.
The following are a description of the block header fields.
Version Number
This a 4-byte field which provides the version number used in the block. There a different block versions that form a part of the history in the development of Bitcoin.
- Version 1 was introduced in the genesis block (January 2009), the very first block generated on the Bitcoin network’s blockchain.
- Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a User Activated Soft Fork (UASF). As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. BIP34 also describes rules for rejecting certain blocks. Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase starting at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930.
- Version 3 blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a UASF. When the fork reached full enforcement (July 2015), it required strict DER encoding of ECDSA signatures in new blocks as described in BIP66. Transactions that don’t use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012).
- Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2 (November 2015) as a UASF became active in December 2015. These blocks now support the new
OP_CHECKLOCKTIMEVERIFYopcode described in that BIP.
(Source Bitcoin.org)
The version refers to which block validation rules the block follows. These rules form part of the protocols described in the section above regarding each version. If the block version number is different from other blocks, then they cannot be a part of the same blockchain. In that case, it would be running on a different chain and could result in a hard fork.
Previous Block Hash
The previous block hash is a 32-byte field that contains the hash of the previous block header. This contains a pointer to the previous block, a very important feature in a blockchain. This information cannot be modified without requiring modifying the previous blocks. Thus if you had 200,000 blocks and you attempt to change the hash value of the previous block, the avalanche effect will occur which means it requires changing the other previous hash values.
This will require plenty of computing power hash rate that will be too difficult. This feature of linking hashes is what provides the block’s security and tamper resistance. It can still be changed, but it would affect the entire blockchain and this would, in theory, require what is called a 51% attack. Reversing all transactions is thus difficult to do on a blockchain due to the hashing of the block header.
The block header uses the SHA256 hashing algorithm. This uses the function:
SHA256(SHA256())SHA256(SHA256(Prev_Block_Header))
This ensures that no previous block can be changed without also changing the block’s header. This feature provides a tamper resistance measure. It thus becomes more expensive trying to reverse a transaction, since it requires changing the block header’s hashes. That utilizes energy-intensive compute resources to recalculate the hashes. In the real world, the miners can repulse this attack by forking the blockchain. In theory, it could thwart the attacker, but once again consensus is key to maintaining valid blockchain information.
Merkle Root
The Merkle Root field is also 32 bytes in length and contains the hash of the blockchain’s Merkle Root. It uses the same function as the previous block header hash. The Merkle Root is derived from the hashes of all transactions included in this block. Hashing makes sure that that none of those transactions can be modified without modifying the entire header. Once again this is a tamper resistance measure that provides security for the block, an important feature of a public, decentralized and trustless system.
The Merkle Root consists of all the TXIDs (transaction ID) of transactions in the block. The TXIDs are placed in the order required by the consensus rules:
- The coinbase transaction’s TXID is placed first.
- Any input in the block can spend an output which also appears in this block if it is a valid spend. It must be a TXID corresponding to the output placed at some point prior to the TXID corresponding to the input. This follows the UTXO (Unspent Transaction Output) rule that a transaction input must be the previous transaction output.
The total length of 32 bytes is the result of the SHA256 hash function. The input is converted from a variable-length value to a fixed value that is 256 bits in length. The Merkle Root can always be traced back to the very root of the data tree structure (i.e. The Merkle Tree) and is a fast and efficient way to verify the data.
Timestamp
The timestamp is a 4 byte filed that is the time measured in Unix epoch time. This is the number of seconds that have elapsed since January 1970. The timestamp begins when the miner started the hashing the header. This must be strictly greater than the median time of the previous 11 blocks. Full nodes will not be accepting blocks with headers that are more than 2 hours in the future according to their clock.
Unix time is not a true representation of UTC. It ignores leap seconds, with each day containing a total of 86,400 seconds (60 seconds/minute x 60 minutes/hour x 24 hours). According to the Bitcoin protocols, the block propagation time must be on average 10 minutes, so the timestamp must fall within the allowable time that is within this range. The variability, however, is due to the difficulty which will be discussed next.
Difficulty Target
The difficulty target is a 4-byte file also referred to as the Bits. The encoded version of the target is a threshold that the block’s header hash must be less than or equal to. The Bits specify a value or target threshold that contains leading zeroes. This is the basis of the difficulty target, which is not the same as the Bits. The difficulty target is adjusted every 2,016 blocks on the Bitcoin network. This information is important for miners in particular.
The difficulty target is coded as a Bitcoin protocol. This determines how difficult the hash value should be based on the network’s total hash rate. When there are too many miners, the hash difficulty increases in order to control the supply of Bitcoin. If the difficulty is too easy, the block propagation time falls below 10 minutes on average. This could exhaust the supply of BTC given very quickly, and hash rates do increases as more powerful mining devices are added to the network. When the block propagation time is more than 10 minutes, the difficulty is too high, so the protocol code ensures that the difficulty must be decreased.
Nonce
The nonce is a 4-byte field that is an arbitrary number of miners change to modify the header hash in order to produce a hash less than or equal to the target threshold. The nonce is like the “magic number” because whoever discovers it first will become the block validator. The reward is then put into the coinbase field and it is given to the miner who discovered the nonce first. The nonce must be equal or less than the difficulty target.
Discovering the nonce is the main activity miners engage in during the consensus mechanism of validating blocks. The miners are competing with one another by trying to solve a cryptographic puzzle that must be below the difficulty target. It was coded in a protocol to be rather difficult so that not just anyone in a permissionless system can discover the nonce. Thus, a difficulty target was specified that adjusts the value based on the network’s total hash rate.
Data Types
Size is measured in bytes (1 byte = 8 bits)
int32_t is a signed integer value
uint32_t is an unsigned integer value
char[32] is a character value that includes hexadecimal values
Block Header Example
The data was obtained using an API call to the Bitcoin blockchain to retrieve the block header information. Here is an example:
The “bits” is the difficulty target which has been encoded into a numeric value. The lower the value of the difficulty target, the harder it is to generate a block. The difficulty value has a hexadecimal form that was converted to 419486617.
The “mrkl_root” is the hash of all the transactions inside the block. This has been hashed using the SHA256 algorithm.
The “nonce” is the discovered value that the miner who validated the block has used. This is the number used to generate the block that was added to the blockchain.
The “prev_block” is the hash of the previous block header. This is what links a block to the rest of the blockchain.
The “time” is indicated when the miners started hashing on the block. The example uses a different format for the time, but it is originally the number of seconds based on the Unix epoch time.
The “ver” field is the version number of the block which follows the consensus rules of that protocol version.
Synopsis
The block header summarizes the block. The fields in the block header provide the unique details of the block. The data are serialized into an 80-byte string that is then hashed for the succeeding block. This provides the link between blocks that form a blockchain on the Bitcoin network.
