!!! Overview
[{$pagename}] is the building [block] of the [Bitcoin] [Blockchain]

Each [{$pagename}] within the [blockchain] is identified by a [hash], generated using the [SHA256] [Cryptographic Hash Function] on the header of the [{$pagename}]. Each [{$pagename}] also references a previous [{$pagename}], known as the parent [{$pagename}], through the "previous block hash" field in the [block] [header]. In other words, each [{$pagename}] contains the hash of its parent inside its own [header]. The sequence of [hash]es linking each block to its parent creates a chain going back all the way to the first block ever created, known as the __genesis block__.

Although a [{$pagename}] has just one parent, it can temporarily have multiple children. Each of the children refers to the same [{$pagename}] as its parent and contains the same (parent) hash in the "previous block hash" field. Multiple children arise during a [blockchain] "fork," a temporary situation that occurs when different [{$pagename}] are discovered almost simultaneously by different miners (see “Blockchain Forks”). Eventually, only one child [{$pagename}] becomes part of the [blockchain] and the "fork" is resolved. Even though a block may have more than one child, each block can have only one parent. This is because a [{$pagename}] has one single "previous block hash" field referencing its single parent.

The "previous block hash" field is inside the [block] [header] and thereby affects the current [{$pagename}]’s [hash]. The child’s own identity changes if the parent’s identity changes. When the parent is modified in any way, the parent’s hash changes. The parent’s changed hash necessitates a change in the "previous block hash" pointer of the child. This in turn causes the child’s hash to change, which requires a change in the pointer of the grandchild, which in turn changes the grandchild, and so on. This cascade effect ensures that once a block has many generations following it, it cannot be changed without forcing a recalculation of all subsequent [{$pagename}]. Because such a recalculation would require enormous computation, the existence of a long chain of blocks makes the [blockchain]’s deep history [immutable], which is a key feature of [bitcoin]’s security.

One way to think about the [blockchain] is like layers in a geological formation, or glacier core sample. The surface layers might change with the seasons, or even be blown away before they have time to settle. But once you go a few inches deep, geological layers become more and more stable. By the time you look a few hundred feet down, you are looking at a snapshot of the past that has remained undisturbed for millions of years. In the [blockchain], the most recent few blocks might be revised if there is a chain recalculation due to a fork. The top six blocks are like a few inches of topsoil. But once you go more deeply into the [blockchain], beyond six blocks, [{$pagename}] are less and less likely to change. After 100 blocks back there is so much stability that the coinbase transaction—the transaction containing newly mined bitcoins—can be spent. A few thousand blocks back (a month) and the [blockchain] is settled history, for all practical purposes. While the [protocol] always allows a chain to be undone by a longer chain and while the possibility of any block being reversed always exists, the probability of such an event decreases as time passes until it becomes infinitesimal.

!! Structure of a [{$pagename}]
A [block] is a container [data] structure that aggregates transactions for inclusion in the public ledger, the [blockchain]. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The [block] [header] is 80 bytes, whereas the average transaction is at least 250 bytes and the average block contains more than 500 transactions. A complete [block], with all transactions, is therefore 1,000 times larger than the [block] [header]. Table 7-1 describes the structure of a block.

%%zebra-table
%%sortable
%%table-filter
||Size||Field||Description
|4 bytes|Block Size|The size of the block, in bytes, following this field
|80 bytes|Block Header|Several fields form the block header
|1-9 bytes (VarInt)|Transaction Counter|How many transactions follow
|Variable|Transactions|The transactions recorded in this block
/%
/%
/%!! Block Header
The block header consists of three sets of block metadata. First, there is a reference to a previous block hash, which connects this block to the previous block in the blockchain. The second set of metadata, namely the difficulty, timestamp, and nonce, relate to the mining competition, as detailed in Chapter 8. The third piece of metadata is the merkle tree root, a data structure used to efficiently summarize all the transactions in the block. Table 7-2 describes the structure of a block header.
%%zebra-table
%%sortable
%%table-filter
||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 [{$pagename}]’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]
/%
/%
/%
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#block_header|Wikipedia:http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#block_header|target='_blank'] - based on information obtained 2018-01-04-