## Why is the scriptSig formatted this way in the Genesis Block (inside function CreateGenesisBlock)

2

I was exploring the function static CBlock CreateGenesisBlock inside src/chainparams.cpp and I was looking at the way Satoshi created its scriptSig:

 txNew.vin[0].scriptSig = CScript() << 486604799 << CScriptNum(4) << std::vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));


CScript is constructing an object of the CScript class with the following inputs:
486604799  is the Nonce
CScriptNum(4) is an extraNonce
pszTimestamp is just a string "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
Why is the scriptSig formatted like this and shouldn't the scriptSig contain the signature of the whole transaction (not just little parts of it) and a public key of the person who signs the transaction?

## Answers

4

The scriptSig field of a coinbase transaction is special. It doesn't need any signatures at all, as no coins are being spent. The ability to produce new coins, which that input represents, is inherent to the protocol - every block is allowed some fixed amount of produced coins. Requiring a signature on it would be wasteful and pointless. Which key should we expect a signature with? Miners don't have identities by design, as it is intended to be permissionless.

Instead, this field just contains arbitrary data the miners chooses. It can function as an "extra nonce", when the nonce in the header overflows. It is used by BIP34 to store the block height. It can further be used to store messages - which is what happened here.

As for why Satoshi chose that specific structure, i'm afraid you'll have to ask him.

Also note that the genesis block is hardcoded by the protocol, so there are no real rules that apply to it. It could have been declared to be anything.

Thank you a lot for your answer! – ddavi031 – 2020-07-14T18:56:45.303

2

It does not need to as the coinbase transaction of each block does not spend any other transaction, hence does not need to satisfy the conditions set by the scriptPubKey of an existing output.