Bitcoin BIP developments threaten merge mining?
-
Quote ~:
Bitcoin is getting serious about using the individual bits of nVersion for softforks (BIP9). This will severly interfer with the current way merge-mining is handled through nVersion. Thus, I think we should push for a fork that changes the merge-mining format so that it does no longer mess with nVersion, and allows us to keep up with upstream development.
Currently, merge-mined blocks signal this fact through a bit in nVersion, and also set the merge-mining “chain id” in higher bits of this number. I propose the following change (that is a hardfork): Starting with the fork block height (or possibly a certain block time, so that this can be deduced without context as nTime is part of the header already), we change the serialisation format of block headers. nVersion will no longer be “abused” and will just match Bitcoin’s version field to 100%, but the initial 80 bytes of the current block header will always be followed by data indicating the merge-mining information - also for non-merge-mined blocks. This additional data could be a new byte that contains the merge-mining information and chain ID. If this byte signals merge-mining, the auxpow follows as before.
