Research

The Bitcoin Genesis Block

"... This message proves that the genesis block was created on or after 3 January 2009, since Satoshi would have had to read the headline before including it in the block..."

This is a living document. If you have any questions, comments, or corrections, please contact StJohn Piano on Tela:
tela.app/id/stjohn_piano/7c51a6

The creation of the Genesis Block:

There was a 6-day delay between the creation of the first block (3 January 2009) and the second block (9 January 2009). The standard block delay is 10 minutes.

One explanation is that Satoshi had already been working on Bitcoin for a long time and the front page of The Times prompted him to release the first version. He then mined the genesis block with a timestamp in the past to match the date of the headline.

A more entertaining theory is that Satoshi was emulating the story of creation from the Book of Genesis.

Image generated at imagine.art: Model = Imagine V4, Prompt = "the bitcoin genesis block"

Join Tela Network, become a consultant, and publish your research on Tela Blog:
tela.network/join

Follow Tela Network on Twitter:
twitter.com/tela_updates

Satoshi's famous message in the Genesis Block:

The first transaction in a block is the "coinbase" transaction. It generates new Bitcoin for the miner who creates it.

A coinbase transaction has no inputs to represent outputs of older transactions. Instead, a fake input is used in the coinbase transaction. The previous output hash is set to a null value, the previous output index is set to the maximum value, and the coinbase scriptSig data can be an arbitrary value (this is useful for miners).

The coinbase scriptSig in the Genesis Block contains Satoshi's famous message. The first 16 bytes are nonsense bytes and can be ignored. The remaining 138 bytes, when converted from hex to ASCII, read as follows:

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

This message proves that the genesis block was created on or after 3 January 2009, since Satoshi would have had to read the headline before including it in the block. It is also a comment on the instability caused by fractional-reserve banking.

How the "bits" and "time" fields in the block format govern Bitcoin mining difficulty and the Bitcoin block interval:

The "bits" field contains the difficulty target threshold. The target threshold is a 256-bit unsigned integer which a header hash must be less than or equal to in order for that header to be a valid addition to the blockchain. As the target threshold gets lower, it gets harder for a miner to find a valid block. A greater number of zeros at the beginning of the target threshold value is an easily visible indicator of the difficulty.

The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

A block's time is included in the 'time' field. Miners are incentivised to use an accurate time value due to the mediantime constraint i.e. that the block's time value must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock. Miners therefore attempt to use an accurate time value so that their blocks are always considered valid by the rest of the network.

The rest of this article contains explanations of the different fields in the Genesis block.

The block in its raw hex form:

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Here is a breakdown of the block into its components:

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - previous block hash
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a - merkle root
29ab5f49 - time
ffff001d - bits
1dac2b7c - nonce
01 - transaction count
01000000 - version
01 - input count
0000000000000000000000000000000000000000000000000000000000000000 - previous output hash
ffffffff - previous output index
4d - script length
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 - scriptSig
ffffffff - sequence
01 - output count
00f2052a01000000 - output value
43 - script length
4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac - scriptPubKey
00000000 - block lock time

The first 6 components comprise the "block header". The block header is followed by the transaction count and the transactions.

In the genesis block, there is a single transaction that starts at the "version" field and ends at the "block lock time" field.

Most values in Bitcoin data are in little-endian format i.e. they're reversed. The exceptions are the hash values, which are in big-endian human-readable order: The previous block hash, the merkle root, the previous output hash, the public key X and Y values in a scriptSig, and the public key hash in a scriptPubKey.

Explanations:

version: The block version number indicates which set of block validation rules to follow.

previous block hash: The double SHA256 hash of the previous block's block header. In the case of the genesis block, no previous block exists, so Satoshi used a zero value.

merkle root: The double SHA256 hash of the merkle tree of the transactions in this block.

time: The block time is the Unix epoch time (the number of seconds since 1 January 1970 UTC) when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.

bits: This encodes the difficulty target threshold for this block in a special compact format. The target threshold is a 256-bit unsigned integer which a header hash must be less than or equal to in order for that header to be a valid addition to the blockchain. As the target threshold gets lower, it gets harder for a miner to find a valid block. A greater number of zeros at the beginning of the target threshold value is an easily visible indicator of the difficulty.

nonce: An arbitrary number that miners change to modify the header hash in order to produce a hash less than or equal to the target threshold. If all 32-bit values are tested, the timestamp can be updated, or the coinbase transaction data can be changed and the merkle root updated.

transaction count: The number of transactions in the block.

Note: The remaining fields in this list are "transaction" fields (rather than block "fields").

version: The transaction version number indicates which set of transaction validation rules to follow.

previous output hash: This is the hash of the transaction containing the output that this new transaction is spending. It is also known as the "txid" ("transaction id"). Note that block explorers will use the txid in little-endian format, while inside Bitcoin it is used in big-endian format.

previous output index: This is the index of the output within the previous transaction.

script length: The length in bytes of the following script.

scriptSig: A program in Bitcoin's Script language that contains the cryptographic proof allowing this previous output to be spent in this transaction. When changed in the coinbase transaction during mining, it's called the "extraNonce".

sequence: This is a legacy feature that was designed to allow multiple signers to agree to update a transaction, increasing the transaction's sequence number to indicate the new version. Sequence can now always be set to 0xffffffff.

output count: The number of outputs in the transaction.

output value: The value in satoshi of this output. In this case, it is 50 Bitcoin.

script length: The length in bytes of the following script.

scriptPubKey: A program in Bitcoin's Script language that contains the cryptographic conditions required to spend this new output in the future.

block lock time: A feature that was designed to ask miners not to mine a transaction until a specified block height was reached. A block lock time of 0x00000000 specifies that the transaction can be mined at any block height after 0. Block lock time can now always be set to 0x00000000.

The block data for the Genesis Block supplied by a Bitcoin node in JSON form:

{
    "bits": "1d00ffff",
    "chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
    "confirmations": 806319,
    "difficulty": 1,
    "hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    "height": 0,
    "mediantime": 1231006505,
    "merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
    "nTx": 1,
    "nextblockhash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
    "nonce": 2083236893,
    "size": 285,
    "strippedsize": 285,
    "time": 1231006505,
    "tx": [
        {
            "hash": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
            "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
            "locktime": 0,
            "size": 204,
            "txid": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
            "version": 1,
            "vin": [
                {
                    "coinbase": "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
                    "sequence": 4294967295
                }
            ],
            "vout": [
                {
                    "n": 0,
                    "scriptPubKey": {
                        "asm": "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG",
                        "desc": "pk(04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f)#vlz6ztea",
                        "hex": "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac",
                        "type": "pubkey"
                    },
                    "value": 50.0
                }
            ],
            "vsize": 204,
            "weight": 816
        }
    ],
    "version": 1,
    "versionHex": "00000001",
    "weight": 1140
}

Explanations:

chainwork: The expected number of hashes required to arrive at this block in the chain. You can't know exactly how many hashes miners performed, but you can calculate the expected number of hashes.

confirmations: The number of blocks that have been added to the chain on top of this block.

difficulty: A measure of the difficulty of finding a new hash of the block header that is under the maximum target threshold value. The minimum difficulty, when the target is at the maximum allowed value, is 1. Difficulty is defined in terms of itself - higher values of difficulty are measured with respect to this minimum difficulty of 1.

hash: The double SHA256 hash of this block's block header.

height: The block number of this block in the chain. The block number of the Genesis Block is 0.

mediantime: The median time of the past 11 block timestamps. A new block must have a timestamp greater than this value. Therefore the mediantime always increases.

nTx: transaction count

nextblockhash: The double SHA256 hash of the next block's block header.

size: The size in bytes of the block, including segregated witness data.

strippedsize: The size of the actual Bitcoin block.

weight: The block weight as defined in BIP 141

versionHex: The block version formatted in hexadecimal

Note: The remaining fields in this list are "transaction" fields (rather than block "fields").

hash: When the transaction is a segwit transaction, the calculation of hash does not include the witness data, whereas the txid does. The hash is therefore the original "txid".

hex: The transaction in its raw hex form.

locktime: Block lock time.

size: The size in bytes of the transaction.

txid: The double SHA256 hash of the transaction, including the segwit witness data.

vin: "vector in": The inputs of the transaction.

coinbase: The coinbase transaction's scriptSig data.

vout: "vector output": The outputs of the transaction.

vsize: The transaction's weighted size under segwit's rules. For non-segwit transactions, size = vsize and vbytes = bytes.

weight: For non-segwit transactions, this is the strippedsize * 4.