1.14 and 1.17 Mining Changes

Ross Nicoll bio photo By Ross Nicoll

With Dogecoin Core 1.14 having shipped, we’re looking ahead to the next release. We do not have a set cadence for these releases, but lean towards assessing releases on a case by case basis. In this case, development effort is focused on Bitcoin Core 0.17 as a base, and we have a semi-functional prototype already. This future release will be Dogecoin Core 1.17.

I wanted to talk about changes that slipped into 1.14.0, and what that means for 1.17. As you may or may not be aware Namecoin first introduced AuxPoW mining, which Dogecoin uses as part of its proof of work. We share a lot of Namecoin’s code for our AuxPoW implementation because, well, it’s open source so why duplicate the effort.

AuxPoW allows us to accept work done towards mining Litecoin (and other Scrypt) blocks as proof of work for Dogecoin, meaning we can always use all Scrypt mining power rather than competing with other coins for it. This improves the security of the Dogecoin blockchain, and avoids excess work being performed (potentially a waste of resources).

Unfortunately, when merging in the latest code from Namecoin it was missed that the target field returned by getauxblock was deprecated, and had been renamed. This has been an intentional divergence from Namecoin for us; our inference is they renamed the field out of a desire to replace it with a version that ordered the value the same way it is presented in getblocktemplate. However the process of replacing this field is complex as there are implementations that depend on the existing functionality.

I am currently testing a fix to this behavioural change, and that should be ready for release shortly.

Looking ahead to Namecoin 0.17 and therefore Dogecoin Core 1.17 there are two new commands, createauxblock and submitnewblock which will later replace getauxblock. We’ll have all three commands in this release for compatibility, but mining pools should prepare to upgrade. These two new commands split the functionality of getauxblock to make it clearer what the intent of a call is, rather than inferring whether the caller meant by number of parameters to the call. This reduces the complexity of the code and risk of error when making calls.

The call syntax and response for these replacement commands is identical to calling getauxblock with no parameters (for createauxblock) and with a block hash and AuxPoW section (for submitauxblock).

I’ll talk more about how these commands work in a later post, but for now just wanted to let you know a fix was coming for the mining behaviour change, and that there are future changes coming in 1.17.