You can see here the coinbase of the genesis block
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
Broken down into hex it looks like this
Size of nBits as varint
0x04
nBits themselves
0xffff001d
Satoshi's message in HEX
0x5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
And between the nBits and Satoshi's message we have these three bytes which should be the extraNonce
0x010445
Which correspond to the code CBigNum(4)
, since 4 is an integer, it's 4 bytes, if this was encoded as a varint, it's value is < 253 as such it would've taken only 1 byte, but as you see there are three bytes.
Upon asking the bitcoin developers on IRC, they told me it's because the BigNum library encodes bits differently.
I started poking around in the Bitcoin source code, specifically the Bignum wrapper, I found many overloaded constructors and operators, but ultimately failed to find how these three bytes are calculated and returned because of my little experience with C++.
However, I believe it's this function
void setulong(unsigned long n)
{
if (!BN_set_word(this, n))
throw bignum_error("CBigNum conversion from unsigned long : BN_set_word failed");
}
However it's still not returning these bytes. So my question is, how is the integer 4 which should still be 0x04
in hex encoded to be this sequence of bytes 0x010445
(big-endian) so that I can do it in C?