Constructing the block header, difficulty representation

ch08.asciidoc

@@ -102,11 +102,20 @@ Any transactions left in the memory pool after the block is filled will remain i
 Bitcoin transactions do not have an expiration time-out. A transaction that is valid now will be valid in perpetuity. However, if a transaction is only propagated across the network once it will persist only as long as it is held in a mining node memory pool. When a mining node is restarted, its memory pool is wiped clear, as it is a transient non-persistent form of storage. While a valid transaction may have been propagated across the network, if it is not executed it may eventually not reside in the memory pool of any miner. Wallet software is expected to retransmit such transactions or reconstruct them with higher fees if they are not successfully executed within a reasonable amount of time.
 
 When Jing's node aggregates all the transactions from the memory pool, the new candidate block has 418 transactions with total transaction fees of 0.09094928 bitcoin. You can see this block in the blockchain using the Bitcoin Core client command line interface:
-
+====
+[source,bash]
 ----
 $ bitcoin-cli getblockhash 277316
 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
+
 $ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
+----
+====
+[[block277316]]
+.Block 277,316
+====
+[source,json]
+----
 {
     "hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
     "confirmations" : 35561,
@@ -130,6 +139,7 @@ $ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2
     "nextblockhash" : "000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
 }
 ----
+====
 
 === The Generation Transaction
 
@@ -144,6 +154,7 @@ $ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda1
 ====
 
 [[generation_tx_example]]
+.Generation Transaction
 ====
 [source,json]
 ----
@@ -265,6 +276,31 @@ The single output of the generation transaction sends the value of 25.09094928 b
 
 === Constructing the Block Header
 
+To construct the block header, the mining node needs to fill in six fields:
+
+[[block_header_structure]]
+.The structure of the block header
+[options="header"]
+|=======
+|Size| Field | Description
+| 4 bytes | Version | A version number to track software/protocol upgrades
+| 32 bytes | Previous Block Hash | A reference to the hash of the previous (parent) block in the chain
+| 32 bytes | Merkle Root | A hash of the root of the Merkle-Tree of this block's transactions
+| 4 bytes | Timestamp | The approximate creation time of this block (seconds from Unix Epoch)
+| 4 bytes | Difficulty Target | The proof-of-work algorithm difficulty target for this block
+| 4 bytes | Nonce | A counter used for the proof-of-work algorithm
+|=======
+
+At the time block 277,316 was mined, the version number describing the block structure is version "2", which is encoded in little-endian format in 4 bytes as +0x02000000+. 
+
+Next, the mining node needs to add the "Previous Block Hash". That is the hash of the block header of block 277,315, the previous block received from the network, which Jing's node has accepted and selected as the parent of the candidate block 277,316. The block header hash for block 277,315 is +0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569+. 
+
+The next step is to summarize all the transactions with a Merkle Tree, in order to add the Merkle Root to the block header. The generation transaction is listed as the first transaction in the block. Then, 418 more transactions are added after it, for a total of 419 transactions in the block. As we saw in the <<merkle_trees>>, there must be an even number of "leaf" nodes in the tree, so the last transaction is duplicated, creating 420 nodes, each containing the hash of one transaction. The transaction hashes are then combined, in pairs, creating each level of the tree, until all the transactions are summarized into one node at the "root" of the tree. The root of the merkle tree summarizes all the transactions into a single 32 byte value +c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e+ which you can see listed as "merkle root" in <<block277316>>
+    
+The mining node will then add a 4-byte timestamp, encoded as a Unix "Epoch" timestamp, which is based on the number of seconds elapsed from January 1st, 1970, midnight UTC/GMT. The time +1388185914+ is equal to Friday, 27 Dec 2013, 23:11:54 UTC/GMT.
+
+Finally, the node fills in the difficulty target, which defines the required proof-of-work difficulty to make this a valid block. The difficulty is stored in the block as a "difficulty bits" metric, which is a mantissa-exponent encoding of the target. The encoding has a one-byte exponent, followed by a 3 byte mantissa (coefficient). In block 277,316, for example, the difficulty bits value is +0x1903a30c+. The first part +0x19+ is a hexadecimal exponent, while the next part +0x03a30c+ is the coefficient. The concept of a difficulty target is explained in <<difficulty_target>> and the "difficulty bits" representation is explained in <<difficulty_bits>>. 
+
 [[mining]]
 === Proof-of-Work (Mining) and Consensus
 ((("Mining", "Proof of Work", "SHA256", "hashing power", "difficulty", "nonce")))
@@ -426,6 +462,26 @@ As you can see, increasing the difficulty by 1 bit causes an exponential increas
 
 At the time of writing this, the network is attempting to find a block whose header hash is less than +000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7+. As you can see, there are a lot of zeroes at the beginning of that hash, meaning that the acceptable range of hashes is much smaller, hence more difficult to find a valid hash. It will take on average more 150 quadrillion hash calculations per second for the network to discover the next block. That seems like an impossible task, but fortunately the network is bringing 500 TH/sec of processing power to bear, which will be able to find a block in about 10 minutes on average. 
 
+==== Difficulty Representation
+
+The formula to calculate the difficulty target from this representation is:
+
+----
+target = coefficient * 2^(8 * (exponent - 3))
+----
+
+Using that formula, we can 
+difficulty bits is 0x1903a30c
+
+target = 0x03a30c * 2^(0x08 * (0x19 - 0x03))^ 
+
+=> target = 0x03a30c * 2^(0x08 * 0x16)^
+=> target = 238,348 * 2^176^
+=> target = 238,348 * 2^176^
+=> target = 9,223,372,036,854,775,807
+=> target = 0x0000000000000003A30C00000000000000000000000000000000000000000000
+----
+
 ==== Difficulty Target and Re-Targetting
 
 Bitcoin is tuned to generate blocks approximately every 10 minutes. This is achieved by automatically adjusting the target difficulty to account for increases and decreases in the available computing power on the network. This process occurs automatically and on every full node independently. Each node recalculates the expected difficulty every 2106 blocks, based on the time it took to hash the previous 2106 blocks. In simple terms: If the network is finding blocks faster than every 10 minutes, the difficulty increases. If block discovery is slower than expected, the difficulty will decrease.