How can the genesis block contain arbitrary data on it if the script is invalid?

Question

The coinbase transaction from the genesis block contains this script: 04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73

It pushes the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" into the stack.

I heard that scriptsig is invalid unless there is only one entry in the stack and that entry is '1'. So this script is invalid.

Is this why people say that the coins generated in the genesis block are unspendable?

Answer 1

For four reasons (each of which individually would be enough):

• The genesis block is valid by definition. It is never validated. It is just by definition the first block of the chain, and every other block has to build on top of it. Put otherwise: the rule for validation of a block at height 0 is "it must match the hash of the genesis block", and not any of the other normal validity rules.

• The script you're referring to is the input of a coinbase transaction. Even if the genesis block weren't valid by definition, or if this were to occur in another block, coinbase input scripts are never actually executed. They're only used for allowing miners to insert extra nonce information into blocks, and (since 2012), the BIP34 height-in-coinbase rule.

• The rule you're referring to (the resulting stack after execution must contain only a single element) is only a policy rule (i.e. transactions violating it won't be relayed by modern Bitcoin Core nodes), but it's not a consensus rule that every node and miner must obey. This rule was at some point proposed as a consensus rule (in BIP62, but it was never adopted as such and then withdrawn). In BIP342 (taproot script execution), this rule is actually a consensus rule, but the case you're referring to is not such a spend.

• The policy rule you're referring to only applies to the final stack after execution of the input (unlocking, scriptSig) and output (locking, scriptPubKey) script. Script execution proceeds by first execution the input script, and then executing the output script of the UTXO being spent on the same initial stack. The rule is only about the final state after both executions, and not after just the input script, so this policy rule doesn't apply. In the case of a coinbase input, there is no output script even, so there is no way it could apply even.

The reason why the genesis coinbase transaction output is unspendable is unrelated to all the above, as it's about its output, not its input. The reason for that is due to the fact the initial software never added the genesis block to its internal database (intentionally or unintentionally), so its output wouldn't be retrievable for spending. The code design in Bitcoin Core is completely different these days, but the behavior of not having the genesis block output spendable was maintained, as the alternative would be hard fork. Instead, in today's software it is simply a hardcoded exception: that particular output cannot be spent.