Invalid height in coinbase bug

[MarkPfennig]

As discussed with ahmed on bitcointalk, stratum-mining and the new Bitmark code base I've created aren't playing nicely.

Specifically, my codebase is bitcoin with scrypt support, and version 2 blocks requiring the height to be in the coinbase. As per https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki#specification

I've tested on multiple miners, cgminer, minerd, the internal miner, they all work correctly, only stratum-mining is faulting.

The below was the submission of found block with height 13

stratum-mining submitting a found block:

2014-07-02 03:44:08,792 DEBUG bitcoin_rpc bitcoin_rpc.submitblock # ['020000000d80bd8601a4e69b2428e668a4ea7c37059dd18f2ad0eb8fd3b6acdeb88d9c23418806c83f72111efab41bf10887e94195632a0d360d5a226f422cfc4175da03dd63b353f0ff0f1e2000974d0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff25010d062f503253482f04dd63b35308f8000001000000000d2f7374726174756d506f6f6c2f000000000100943577000000001976a914987dd9a879208fac5d9c1b0944bb27c7fb4e123d88ac00000000']

Block::print() output from bitmark debug log for above submitted block:

2014-07-02 01:44:08 CBlock(hash=f07c28f6eca5cec7f7700a6154b85474700984f4a93e82eaf9f2c49022b8383a, pow=000004b7d8f016751d5adf6978ae635ab7f995cc32b4222d1a1d2fe7b21d6ff3, ver=2, hashPrevBlock=239c8db8deacb6d38febd02a8fd19d05377ceaa468e628249be6a40186bd800d, hashMerkleRoot=03da7541fc2c426f225a0d360d2a639541e98708f11bb4fa1e11723fc8068841, nTime=1404265437, nBits=1e0ffff0, nNonce=1301741600, vtx=1)
2014-07-02 01:44:08   CTransaction(hash=03da7541fc, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 010d062f503253482f04dd63b35308f8000001000000000d2f7374726174756d506f6f6c2f, nSequence=0)
    CTxOut(nValue=20.00000000, scriptPubKey=OP_DUP OP_HASH160 987dd9a87920)
2014-07-02 01:44:08   vMerkleTree: 03da7541fc2c426f225a0d360d2a639541e98708f11bb4fa1e11723fc8068841
2014-07-02 01:44:08 ERROR: AcceptBlock() : block height mismatch in coinbase
2014-07-02 01:44:08 ERROR: ProcessBlock() : AcceptBlock FAILED

Apologies as I haven't dissected it to find the exact error. I have checked that getblocktemplate is returning the right value:

{
    "version" : 2,
    "previousblockhash" : "239c8db8deacb6d38febd02a8fd19d05377ceaa468e628249be6a40186bd800d",
    "transactions" : [
    ],
    "coinbaseaux" : {
        "flags" : "062f503253482f"
    },
    "coinbasevalue" : 2000000000,
    "target" : "00000ffff0000000000000000000000000000000000000000000000000000000",
    "mintime" : 1404228423,
    "mutable" : [
        "time",
        "transactions",
        "prevblock"
    ],
    "noncerange" : "00000000ffffffff",
    "sigoplimit" : 20000,
    "sizelimit" : 1000000,
    "curtime" : 1404265970,
    "bits" : "1e0ffff0",
    "height" : 13
}

To be explicit, the error is being thrown within Bitmark on line 2408, code here: https://github.com/coinsolidation/bitmark/blob/master/src/main.cpp#L2408

I'll monitor the thread to see if I can be of any further assistance.

[MarkPfennig]

I've just noticed, the coinbase starts 010d (height is 1 byte, then heigh in little endian 0d = 13) which is correct for the block height.. I'll double check the Bitmark code, just in case the bitcoin dev's have hard coded 03 in their as they expect it to be 3 bytes on the bitcoin network.

[MarkPfennig]

So, this only happens when the block height is 16 or below, and only with stratum mining. After 0 code changes to stratum-mining and bitmark, it works from above block 17 onwards.

I've reset the blockchain and tried again, rejects all the way to 16 and then fine. Very strange.

Consider it fixed I think, I'll make a note in my own repo

[ahmedbodi]

hmm thats weird then

[MarkPfennig]

I can confirm this is a bug particular to stratum-mining, replicated it 3 times.

Perhaps the block height is encoded incompatibly when below 17, since in hex it is a single char instead of two?

[tuaris]

I am wondering if this has been figured out? Is it because it was hard coded to 3 bytes?
I took a deeper look and I don't see any difference in the amount of digits between 16 and 17 when encoded

import binascii

def ser_number(n, min_size = 1):
    # Little Endian
    # For encoding nHeight into coinbase
    s = bytearray(b'\1')

    while n > 127:
        s[0] += 1
        s.append(n % 256)
        n //= 256

    s.append(n)

    # Satisify Minumim Length
    if min_size < 1:
        min_size = 1

    while len(s) < min_size + 1:
        s.append(0)
        s[0] += 1

    return bytes(s)

print "Encoded 17: %s" % binascii.hexlify(ser_number(17))
print "Encoded 16: %s" % binascii.hexlify(ser_number(16))

Result

Encoded 17: 0111
Encoded 16: 0110

Even forcing 3 bytes, it still rejects blocks until 17

Encoded 17: 03110000
Encoded 16: 03100000

[Infernoman]

Also seeing this issue with a new PIVX clone. Trying to test if it fixes itself after block 16. which i'm guessing it does.

before block 16 it appends a dummy script to the coinbase mentioned here
https://github.com/PIVX-Project/PIVX/blob/7488a2721da8a4defc08d145dadd3c3065e2735d/test/functional/test_framework/blocktools.py#L57

[Infernoman]

also talked about here as well. qtumproject/qtum#15

Which makes me think its coin related. I've attempted the changes described there but pivx has no consensus.bip34height or consensus.bip34hash that I can find. and adding the simple "00 >> " to the genesis block scriptsig and re creating didn't work for me.

EDIT: mining with the internal miner past block 16 then starting stratum-mining worked.

[ahmedbodi]

😂 welcome back to the scene. Yeah the problem is somewhere in how the block is serialised

[Infernoman]

😂 welcome back to the scene. Yeah the problem is somewhere in how the block is serialised

Thanks man haha. I'm slowly getting back into things lol but that was never my forte. If you take a look at qtum projects pull request 16 it shows how they do it for the genesis. maybe that will be of some use? or the reference from the framework tests.

def script_BIP34_coinbase_height(height):
    if height <= 16:
        res = CScriptOp.encode_op_n(height)
        # Append dummy to increase scriptSig size above 2 (see bad-cb-length consensus rule)
        return CScript([res, OP_1])
    return CScript([CScriptNum(height)])

https://github.com/qtumproject/qtum/pull/16/files

[ahmedbodi]

that looks about right, ive not worked on this forever, the changes ive done recently were just cleanup mostly to make it work in a sorta way for someone