The mystery of the Genesis block

When the Bitcoin software was publicly announced in 2009, it was important that nodes joining the network could build a common history of the blockchain. Satoshi Nakamoto accomplished this by hardcoding in the “Genesis block” in the Bitcoin software. While blocks in the Bitcoin network are normally mined by nodes in the network, it was important for there to be a single source of truth for nodes to build the blockchain from when joining the network, even if they were the first node to ever join the network. By hardcoding the Genesis block into the Bitcoin code, there was a guarantee that nodes joining the network all started at the same beginning.

The Genesis block is shrouded in mystique. Encoded in the first coinbase transaction is a string: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” It is widely accepted that Satoshi included this string as a timestamp for the Genesis block, linking it to January 3, 2009.

In court over the last few weeks, Craig Wright made an interesting statement regarding the Genesis block that prompted ridicule. He said (using a rough transcript of the court proceedings):

“The Genesis block isn’t mined. It’s an anchor block. It’s designed so that you can’t spend it because if you spend it, it actually could unravel the end. It’s like if you’re knitting or sewing. You have to tie off the thread to make sure it doesn’t break. So the blockchain requires a block that is not like a mined block. It is not mined.”

A lazily posted quotation of Dr. Wright’s statement prompted ridicule from BTC Core developers Matt Corallo and Peter Todd, with the former saying it was the “dumbest thing ever said about Bitcoin” and the latter dreaming about framing the quote on his wall.

Decoding the Genesis block

To understand the Genesis block, we need to contextualize it using the original Satoshi client.

The hash of the Genesis block was listed in the main.cpp file of the repository:

const uint256 hashGenesisBlock(“0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f
1b60a8ce26f”);

In this same file, the code does a check to see if the node has recorded the genesis block into the node’s block database. This block contains a 50 bitcoin coinbase payout to the address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa (though it is noted that the transaction is actually coded as a Pay to Public Key transaction). All of the info regarding the Genesis block is kept as commented code beginning on line 1439 of main.cpp.

The node kept two databases—a database of blocks and a database of transactions. The node included the Genesis block in its block database but excluded the coinbase transaction from the transaction database. As a result, any attempted spend of the Genesis block would attempt to spend coins that don’t exist in the node’s transaction database and be rejected by the software. The coins are locked using a standard Pay to Public Key (P2PK) output script, where a valid signature using the private key could unlock the coins as an input to a new transaction, but only if the parent transaction was recognized by the node software in its transaction database.

It’s important to note that while the software leaves this transaction out of its transaction database, there is nothing that precludes a node from adding it to its transaction database manually (via hard fork). If a node did this and had a valid unlocking script (signature) for the transaction, the Genesis block could be spent on that chain. If the majority of hash power on the network decided to include this spending transaction, then the Genesis block could definitely be spent. However, by excluding the Genesis coinbase transaction from the transaction database, it is clear from the original code that Satoshi clearly intended for the Genesis block transaction to remain unspent.

The Genesis Block as an Anchor

Satoshi wrote a comment in the original code that defines the Genesis block as the “root” of the blockchain: “The block chain is a tree shaped structure starting with the genesis block at the root, with each block potentially having multiple candidates to be the next block.”

While the subsequent blocks have potentially multiple candidates, the Genesis block is established as an anchor to which all possible branches are built from. To be a good anchor, it is important that nodes in the network have the anchor. Since the Genesis block contains just one transaction in it (the coinbase transaction), a spend of this transaction would introduce a problem to the network: If all of the transactions in the block are spent, then the block itself can be pruned from every node on the network. This would then enable a node to prune all subsequent blocks as the coins in them are spent. This would completely break the immutability property of the historical record and cause big problems for anyone attempting to sync the chain of block headers, let alone the full blockchain. This would “unravel” the blockchain, so to speak.

Remember, the novel solution Bitcoin uses to solve the double spending problem of electronic cash begins with the use of a timestamp server, with “each additional timestamp [block hash] reinforcing the ones before it.” If the first 1000 blocks can be pruned by a node, then the 1001^st block becomes the new anchor, erasing 1000 blocks of history. It would also be trivial for a modern ASIC to create 1000 blocks of history with fake timestamps in an attempt to trick/attack the rest of the network. Without a single anchor, how do you know that what you’re syncing with is even Bitcoin?

Unspendable

Now that we’ve covered why it is important that the Genesis block remains unspendable, and the truth regarding Dr. Wright’s statement on the “unraveling” of the chain, we still have an unresolved problem—is it actually unspendable?

To BTC Core developers like Matt Corallo and Peter Todd, it has to be unspendable because the current BTC Core software hardcodes the exclusion of the Genesis block coinbase transaction from the UTXO set. Developers like Matt and Peter, who have very little understanding for the economic system that Satoshi Nakamoto created, don’t think Bitcoin can undergo hard forks. Besides misunderstanding Satoshi’s definition of nodes and advocating against hard forks, they go as far to say that hard forks are impossible despite Bitcoin hard forking several times under Satoshi’s leadership. As BSV has shown in restoring the original Satoshi protocol, hard forks are a normal part of Nakamoto Consensus to upgrade the network.

Matt, Peter, and the other hat wearers can’t comprehend Dr. Wright’s statement about spends of the Genesis Block “unraveling” the chain because they have a limited understanding of what Bitcoin is. As we covered above, spending the Genesis Block is technically possible if the corresponding private key is used to create a signature and the majority of nodes (miners) on the network hard fork the network to include the initial Genesis transaction and the corresponding spending transaction.

If Satoshi understood how dangerous spending the Genesis block transaction could be, then is this scenario a threat to Bitcoin should Satoshi create a valid signature with the private key corresponding to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

It turns out that Satoshi ensured that even he himself could not cause the unraveling of the chain.

An Unknown Private Key

In ECDSA, the digital signature algorithm used in Bitcoin, signatures are composed of a pair of integers—r and s. r is the x-coordinate of a securely but randomly determined point on the elliptic curve, and s is a function of the private key used to create the signature and a hash of the message that is signed (in Bitcoin, the message is the transaction itself). For most use cases this is pretty straightforward—the holder of a private key can generate a signature, and others can validate that the public key that corresponds to the private key that matches the signature.

In Bitcoin, this mechanism is utilized for Pay to Public Key transactions as outlined in the whitepaper itself:

This means that any coins locked up in a public key can be spent with the corresponding private key. This introduces our aforementioned vulnerability where the corresponding private key to the public key used in the Genesis block coinbase transaction could cause an “unraveling” of the blockchain.

However, it turns out that Satoshi Nakamoto solved for this vulnerability at Bitcoin’s Genesis.

In a blog post “The Genesis of Genesis” dated April 12, 2019, Craig Wright waxes poetically on the circumstances surrounding the launch of Bitcoin. Towards the end, he finally provides some background on how the Genesis block was constructed. He references a technique that can be used to create an “Unknown Private Key.” Cited from Advances in Elliptic Curve Cryptography, we are introduced to a technique to generate a public key from a random value of (r,s) using the hash of any message m. Utilizing this technique, we see that it is theoretically possible to produce a public key for which the corresponding private key is unknown to even Satoshi Nakamoto himself:

This could be made to be even more complex—the private key could be a combination of information which could never be known to one individual person. This introduces an interesting question—if no private key for the Genesis block exists, does Satoshi Nakamoto have information about the message m that was used to generate the signature that produced the public key used for the Genesis Block coinbase transaction?

In the paragraph preceding this section, we see a section titled “Self-Signed Signatures”:

In this, we see that it is possible to create a self-signed Bitcoin transaction using a private key that is computed after the creation of the signature. Is it possible that Satoshi Nakamoto holds a private key that can prove the creation of the message m used to generate the public key used in the Genesis block coinbase transaction, while not being able to sign the Genesis block itself?

I submit that the Genesis block coinbase transaction remains a mystery to me, but I imagine it won’t remain a mystery forever.