BIP-34 claims that in coinbase transactions, the scriptSig ought to include the block top. It says the format of that is “serialized CScript”, i.e. a byte indicating the size of the quantity (n), after which n bytes in little-endian format.
This works if you happen to have a look at e.g. the latest block as of this writing—block 640037—whose coinbase scriptSig begins with these 4 bytes: 0x0325c409. 0x03 signifies the size, after which we’ve (0x25=37 * 256^0) + (0xc4=196 * 256^1) + (0x09=9 * 256^2), or 37 + 50176 + 589824 = 640037.
For apparent causes mainnet and testnet won’t ever have to encode heights 1-16 of their coinbase. However regtest nodes will. Once I run a recent regtest node (v0.19.1) and generate a pair blocks, I get coinbase scriptSigs that seem like this:
top 1: 0x510101
top 2: 0x520101
...
top 16: 0x600101
Clearly it is not serialized CScript, a minimum of within the format described in BIP-34. If it had been, these first bytes would point out information lengths of 81, 82, and 96 respectively, clearly ridiculous. The precise encodings of 1, 2, and 16 in serialized CScript are 0x0101, 0x0102, and 0x0110. It seems to be to me just like the format is top+80 adopted by 0x0101. And for some purpose this solely persists for the primary 16 blocks, as 17’s scriptSig is 0x01110101.
I attempted trying by way of the bitcoin supply code, however I do not write a lot C++ so it is arduous to inform what is going on on. No documentation—within the supply (so far as I can inform) or the PR for BIP-34 or within the BIP itself appears to point that heights 1-16 would have a distinct format from each different top.
Why is that this occurring?