Cool, thanks for this information Pooya!
Cheers McStone
Topic: Mining BTC: Restrictions on version field (Read 177 times)
I know of 3 version bumps so far which means block versions can not be smaller than 4 anymore. Bigger version numbers are allowed for forward compatibility (that means if someday we mandate version 5 the old nodes won't reject it).
Version 1: was the initial design.
Version 2: activates BIP-34 (block height in header is mandatory)
Version 3: activates the strict DER encoding from BIP-66
Version 4: activates a new OP code called OP_OP_CheckLocktimeVerify explained in BIP-65
Version 1: was the initial design.
Version 2: activates BIP-34 (block height in header is mandatory)
Version 3: activates the strict DER encoding from BIP-66
Version 4: activates a new OP code called OP_OP_CheckLocktimeVerify explained in BIP-65
Hi guys,
I know that some miners manipulate the version field (and not only the nonce field) to have more possibilities to try without changing the extra nonce field (because this would need a rehash of the merkle tree).
Does anybody know about any restrictions on the version field? I mean it should state version 2, but will bitcoin core accept any value of the 2^32 possibilities in that field?
If there are any restrictions, please point me to the corresponding bip document, I could not find anything usefull myself :/
Thanks & cheers,
McStone
I know that some miners manipulate the version field (and not only the nonce field) to have more possibilities to try without changing the extra nonce field (because this would need a rehash of the merkle tree).
Does anybody know about any restrictions on the version field? I mean it should state version 2, but will bitcoin core accept any value of the 2^32 possibilities in that field?
If there are any restrictions, please point me to the corresponding bip document, I could not find anything usefull myself :/
Thanks & cheers,
McStone
Jump to: