cculianu
commented
4 years ago I pushed a commit just now that removes some of this data, but still leaves some of it. Here is the data removed:
flags_length, 1 byteflags, 0-4 bytescoinbase_sig_string_len, 1 byte
In addition, the timestamp field has been made a fixed size, 8-byte integer. This shaves off 2 bytes of average.
On average about 4 bytes were saved. Not a huge savings. I'm wary to delete the other fields (especially the timestamp and the nonce_length) because I'm unclear yet what they do. I am also unclear about how the pool defends against attacks where a user can fake their hash rate by submitting multiple duplicate shares. I suspect the timestamp plays into this.
Yeah man good call. There's all this crap that's inserted before the first '
/' character in the coinbase scriptsig. For (my and your) reference, here's the stuff inserted:block_height- (4 bytes), this is required as per BTC/BCH consensus rules as of BIP34.flags_length- (1 byte), this is always 0 for now. But it takes up 1 byte. It's the length of theflagsfield that follows.flags- which is byte data that comes fromgetblocktemplate's["coinbaseaux"]["flags"]response (currently always 0 bytes).timestamp- (7-10 bytes). Basicallystruct timespec.tv_sec+timespec.tv_nsec, in a compact form. This is seconds + nanoseconds (with length bytes), basically.nonce_length- (1 byte) - The total length of the twononce#fields below.nonce1- (2-8 bytes) - Some random bytes. The length of this is configurable as conf file variablenonce1length. Default if unspecified:4bytes.nonce2- (2-8 bytes) - Some random bytes again. The length of this is configurable as conf file variablenonce2length. Default if unspecified:8bytes if !proxy mode,0bytes otherwise.coinbase_sig_string_len- (1 byte) - The length of the belowcoinbase_sig_stringfield.coinbase_sig_string- (variable, up to remainder of 100-byte space that's left [usually about ~73 bytes)With the exception of
block_heightabove (which is required by bitcoin), potentially all of the above can be removed. However it looks like ck went to great care to nonceify and otherwise uniquely mark each work unit generated by doing this to the coinbase. I can't be sure yet what effects removing this data has on mining, or on forging work unit results to game the hash rate, etc. I have to be very careful here.This response is just to illuminate the discussion so we know what is there (and what can be potentially removed).