The first block in the blockchain is the genesis block
The details of the genisis block are hardcoded into the client
If there are 6 blocks on top of a block the block is considered stable
If there are 100 blocks on top of a block the coinbase in the block can be spent
The block header is 80 bytes and can contain 4,000,000 bytes of data
A block can be identified by its commitment hash and block height
Merkle Tree
They are also called binary hash tree
They are binary trees that contain cryptographic hashes
Stores the summary of all the transactions in the block
In Bitcoin SHA256 is applied twice to generate the hash of the transactions
The hashes of the individual transactions for the leaf nodes in the tree
If there are odd transactions the last transaction is duplicated
If at any level in the tree there are odd hashes the last hash is duplicated
To prove if a transaction is in the root we only need hashes
Using these hashes the Merkle path/authentication path can be constructed
To prove that exists in the root only 4 hashes are required
Lightweight Clients
Lightweight clients only have the block header and some of the transactions
To verify if a transaction is present in a block they calculate the merkle path
SPV clients use Bloom Filters to limit that transactions that they receive from peers
The peers will send the client a merkleblock message
The message contains the block header as well as the merkle path linking the interested transaction to the block
SPV client uses block header to check if the block is linked to the previous block
Block Headers
Represents the current version/upgrade of the Bitcoin system
Nowadays this field is also used as an extra nonce field when the normal nonce field is exhausted
Each SegWit transaction is listed using its witness transaction id (wtxid)
The hash that is generated by pairwise hashing then is called witness root hash
The witness root hash is added an output of the coinbase transaction
This is skipped if no SegWit transactions are present in the block
For all transactions in the block the transaction id (txid) is calculated
This values is Merkle hashed to generate the Merkle root
The Merkle root is stored in the block header
The nonce field is initially set to all zeros
Candidate Block
Candidate Block: Block created by miner to add to the blockchain
New transactions are saved in the nodes mempool as unverified transactions
Once its verified by a full node it can be included in a candidate block
Transactions are prioritized to be added to a block based on transaction fee
Miners start mining a new candidate block as soon as they receive the previous valid block on the network
The new candidate blocks created will contain a commitment (reference) to the previous block in the chain
Coinbase Transaction
Is the first transaction in a block
Contains the bitcoin address of the miner (used to send reward)
Subsidiary and the total transaction fees in the block is sent to the address
The correct subsidiary value (new bitcoins) is calculated based on the block height
Coinbase transactions do not spend any UTXOs
They have a single input (coinbase input) which implicitly contains the block reward
There should be at least one output. Most modern transactions have 2 outputs
The output field also stores the witness root hash
In the coinbase transaction the transaction hash field is set to all zeros
The output index field is set to 8 Fs
The input script is replaced with the coinbase data field
The coinbase data must start with the height of the block and can be followed by any arbitrary data