Title: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: Farthom on January 17, 2014, 02:39:05 AM I am working on a self education project, where I am attempting to build a cheap miner application. I have set up "testnet in a box" and have written a small miner that builds version 2 blocks. The miner mines successfully, all blocks up to and including 127, but when attempting to submit block 128 blocks become rejected citing error "AcceptBlock() : block height mismatch in coinbase"
The coinbase script I am using looks like this: (example does not include the script length varint prefix) 0180 00002f503253482f04b8864e50080800000200000001072f736c7573682f It is curious, how the block that fails is the one immediately past the max value of a signed byte (127) I suspect there may be a genuine bug here, related to how bitcoin computes the expected prefix. Internally height is stored as a "signed" int: (Collected from AcceptBlock() function in main.cpp) int nHeight = 0; I suspect errors occur when these signed values get compacted into a variable integer. We may simply have never seen this, because of the possibility block version 2 was not introduced until both testnet and mainnet were sufficiently long to mask the problem. Sadly, I don't have the environment or tools set up to compile and rake around in bitcoin code. Can someone here more equipped, and more knowledgeable than I help me investigate this? I'd be curious of the result of the following snippit of code: int nHeight = 128; CScript expect = CScript() << nHeight; See if the bytes built by CScript turn out to be "0180" as expected. Thanks in advance! Matt Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: Farthom on January 17, 2014, 02:47:59 AM In case anyone would like more context here, this is an example attempted submission. (Submitted hex to "submitblock")
0200000062BDE75A8EF452C5489925E0439FFB42DA9C03B9152E4F361C75C2D400000000A548FD7 DADA0874163A7480A114F1EB2DE0A1BA0CFF667444867A421907865A14999D852FFFF001D600B96 520101000000010000000000000000000000000000000000000000000000000000000000000000f fffffff20018000002f503253482f04b8864e50080800000209020000072f736c7573682f000000 000100f2052a010000001976a91445434bcc52d8e4255d1a5d624854b11fd3a9853188ac0000000 Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: techwtf on January 17, 2014, 03:04:39 AM the last byte should be less than or equal 127, the correct encoding is "02 80 00".
maybe you should use unsigned int. Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: Farthom on January 17, 2014, 03:27:07 AM I'm confused, the varint spec says single byte storage is good up to 252
< 0xfd 1 uint8_t Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: Farthom on January 17, 2014, 03:37:03 AM I'm also assuming it uses "varint" as specified on the bitcoin wiki. I guess I am confused over what determines the "length" of a number.
Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: deepceleron on January 17, 2014, 04:12:20 PM It depends on which "varint" is being used...
Quote // Variable-length integers: bytes are a MSB base-128 encoding of the number. // The high bit in each byte signifies whether another digit follows. To make // the encoding is one-to-one, one is subtracted from all but the last digit. // Thus, the byte sequence a[] with length len, where all but the last byte // has bit 128 set, encodes the number: // // (a[len-1] & 0x7F) + sum(i=1..len-1, 128^i*((a[len-i-1] & 0x7F)+1)) // // Properties: // * Very small (0-127: 1 byte, 128-16511: 2 bytes, 16512-2113663: 3 bytes) // * Every integer has exactly one encoding // * Encoding does not depend on size of original integer type // * No redundancy: every (infinite) byte sequence corresponds to a list // of encoded integers. // // 0: [0x00] 256: [0x81 0x00] // 1: [0x01] 16383: [0xFE 0x7F] // 127: [0x7F] 16384: [0xFF 0x00] // 128: [0x80 0x00] 16511: [0x80 0xFF 0x7F] // 255: [0x80 0x7F] 65535: [0x82 0xFD 0x7F] // 2^32: [0x8E 0xFE 0xFE 0xFF 0x00] the DER-encoded signatures uses a data format with octet lengths specified in ASN.1 http://luca.ntop.org/Teaching/Appunti/asn1.html Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: TierNolan on January 17, 2014, 04:20:58 PM BIP-34 (https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) defines it as
byte: length byte[length]: height It doesn't define if height is signed or not. I think the likely problem is that it is interpreted as a signed number. 01 80 means -128 in signed binary. You need to add a 00 byte to guarantee that it works. 02 0080 would be 128. Title: Re: Unable to mine blocks 128 and beyond using version 2 blocks. Post by: Farthom on January 18, 2014, 04:03:55 AM Thank you deepceleron for your answer. I'm convinced what you posted is correct, but I am stumped by one last thing. I've used the "BouncyCastle" library for .NET to perform this encoding. Sample code:
DerInteger integ = new DerInteger((int)template.Height); byte[] heightBytes = integ.GetDerEncoded(); string hex = Util.ByteArrayToString(heightBytes); hex = hex.Substring(2); //Strip off the INTEGER starting tag "02" For value 128 this results in: 02 00 80 Rather than the expected 02 80 00 Why does bitcoin differ in byte order from the specification? I suppose it is easy enough to write some byte order reversing logic, but I want to make sure I'm not missing something. |