9.The Blockchain

Introduction

The blockchain data structure: ordered back-linked list of blocks of tx

bitcoin core client stores its metadata using Google's LevelDB.

hash: SHA256 cryptographic hash algorithm

Eventually, only one child block becomes part of the blockchain and the “fork” is resolved

each block can have only one parent

 

*cascade effect*

The “previous block hash” field is inside the block header and thereby affects the cur‐ rent block’s hash. When the parent is modified, its hash changes and so does child's hash->requires change its pointer.

 

Structure of a Block

The structure of a block

Block Header

consists of three sets of block metadata:

1. a ref to a prev. block hash - connection

2. nonce - difficulty;timestamp

3. Merkle Tree root - DS used for efficiency (sum. all the tx in the block)

 

The structure of the block header

 

Block Identifiers - Block Header Hash and Block Height

block header hash - unique; identifies a block uniquely and unambiguously and can be independently derived by any node by simply hashing the block header

- is not actually included inside the block's DS / neither transmitted on the network

- instead it is computed by each node as the block is received from the network

 

block height - not a unique identifier (While a single block will always have a specific and invariant block height, the reverse is not true.)

 

The Genesis Block

:The first block in the blockchain; common ancestor

 

Linking Blocks in the Blockchain

To establish a link, a node will examine the incoming block header and look for the “previous block hash.

 

Merkle Trees(binary hash tree)

summarize all the tx in a block;verify whether a tx is included in it.

- formation: a merkle tree is constructed by recursively hashing pairs of nodes until there is only one hash, called the root, or merkle root

- 2*log2(N)

- process: Consecutive pairs of leaf nodes are then summarized in a parent node, by concatenating the two hashes and hashing them together

- binary tree -> needs an even number of leaf nodes. if odd: last tx hash duplicated (balanced tree)

- whether there is one transaction or a hundred thousand transactions in the block, the merkle root always summarizes them into 32 bytes

- merkle path(authentication path): prove that a specific tx is included in a block: node only needs to produce log2(n) 32-byte hashes.

Q. This allows bitcoin nodes to efficiently pro‐ duce paths of 10 or 12 hashes (320–384 bytes), which can provide proof of a single transaction out of more than a thousand transactions in a megabyte-sized block.

 

Merkle Trees and Simplified Payment Verification (SPV)

Merkle trees are used extensively by SPV nodes - they don’t have all transactions and do not download full blocks, just block headers

*tx recording process*

When a peer sees a transaction that matches the bloom filter -> send merkleblock message -> SPV node can use this merkle path to connect the tx to the block and verify that the transaction is included in the block + link the block to the rest of the blockchain

 

Bitcoin’s Test Blockchains

mainnet : The “main” bitcoin blockchain, the one created by Satoshi Nakamoto on January 3rd, 2009, the one with the genesis block

 

Testnet—Bitcoin’s Testing Playground

:a fully featured live P2P network

- any sw dvpt for bitcoin mainnet should first be tested on testnet with test coins

- the testnet has to be scrapped and restarted from a new genesis block, resetting the difficulty(due to some ppl using advanced mining equipment)

- use vm inage -> efficient