Different MerkleRoot & StakeRoot values from NiceHash mining.notify messages.

[dnldd]

Reconstructing a solved block for the in-progress NiceHash implementation
isn't going according to plan. I've been getting work submissions from the service but haven't been able to reconstruct blocks successfully. NiceHash support isn't being forthcoming either. I've been deconstructing work from their service instead to spot differences in implementations an I think I found it.

These work notifications were taking around the same time, this is is work is from NiceHash's decred service,

2021-01-27 14:07:48.234 [DBG] MN: message is {"id":null,"method":"mining.notify","params":["00000000fa36e5d9","845cb9c2ab5208d3be1b15021fb14e9c3fdf431b2a22c0c30000000000000000","3c78b309ae3e64f890891adf9cf254ea17a7ea760a556393cab5ec8dbfb64297ab3c5d70249a560a84562d852e4aed1d90e1d90ed9d501b546f7698f5761ac220100daca66b82e30050000003ea300004a3d2b18c67546de030000002afd0700380c0000ae73116000000000","07000000",[],"07000000","182b3d4a","601173ae",true]}

and this is from my decred node.

❯ ./dcrctl getwork
{
  "data": "08000000c2b95c84d30852ab02151bbe9c4eb11f1b43df3fc3c0222a00000000000000002cd0b71b5e4b8cdba054cf00801d89e91db29d5a04d5ba5fd9df31b419b9f8185e56e0175ad94901664302dfbc9d4772958fd1203bd15f24b0cf6a36ec6aac830100daca66b82e30050000003ea300004a3d2b18c67546de030000002afd0700380c0000ca731160000000000000000000000000000000000000000000000000000000000000000000000000070000008000000100000000000005a0",
  "target": "0000000000000000000000000000000000000000004a3d2b0000000000000000"
}

params[2], which is a concatenation starting from the merkleroot to the Nonce of the block header in the work notification, is the interesting bit here, which is data[72,288], they are identical (expected difference with the timestamp) except for the merkleroot and stakeroot. It seems NiceHash is wrongly calculating the merkleroot and stakeroot instead of using what's already provided in the work submissions.

Here is params[2] breakdown into its parts:

MerkleRoot: 3c78b309ae3e64f890891adf9cf254ea17a7ea760a556393cab5ec8dbfb64297
StakeRoot: ab3c5d70249a560a84562d852e4aed1d90e1d90ed9d501b546f7698f5761ac22
VoteBits: 0100
FinalState: daca66b82e30
Voters: 0500
FreshStake: 00
Revocations: 00
PoolSize: 3ea30000
Bits: 4a3d2b18
SBits: c67546de03000000
Height: 2afd0700
Size: 380c0000
Timestamp: ae731160
Nonce: 00000000

The referenced block is https://explorer.dcrdata.org/block/00000000000000002a22c0c33fdf431b1fb14e9cbe1b1502ab5208d3845cb9c2.
I'm still tinkering, will update this issue if anything else of note is discovered. Any suggestions welcome.

[davecgh]

Everything is on an entirely new hash function now so this doesn't apply anymore. Closing.