[0.6.2] deps: update dcrd/dcrwallet to 1.8 modules

[chappjc]

Also cherry-pick #2358

[chappjc]

Tested:

• interactive dcr-btc trade with native SPV wallet
• interactive dcr-btc trade with external dcrwallet
• simnet-trade-test success test with native SPV wallet
• simnet-trade-test success test with external dcrwallet
• simnet-trade-test all tests with native SPV wallet
• simnet-trade-test all tests with external dcrwallet

[buck54321]

Oh. Still draft. Well I've tested manually and with simnet-trade tests as well, and everything seems to be in order. Fixes my harness issues too.

[davecgh]

Confirmed all of the dcrd module updates.

While it isn't necessary for this PR, keep in mind that the simnet harness will likely need to be regenerated with the new blake3 hashes if you want it to be valid to sync from scratch versus starting up with them already all assumed valid.

[chappjc]

While it isn't necessary for this PR, keep in mind that the simnet harness will likely need to be regenerated with the new blake3 hashes if you want it to be valid to sync from scratch versus starting up with them already all assumed valid.

Thanks. Did this in dcrdex. I don't even recall if we have a harness archive for dcrdata, but will check.

The txhelpers/subsidy.go functions need work though. They are using deprecated functions and won't work as expected I think

[chappjc]

Oh, this is dcrdex. Though you were commenting on the dcrdata PR. Yah, the harness is already updated in #2358

[davecgh]

Oh, this is dcrdex. Though you were commenting on the dcrdata PR. Yah, the harness is already updated in #2358

I know you updated it for the subsidy change, but I didn't think you had done it for the hash and difficulty algo change in there?

[chappjc]

I know you updated it for the subsidy change, but I didn't think you had done it for the hash and difficulty algo change in there?

The harness tarball was regenerated, yes. Regarding the hash function change and the diff algo, are you referring to dcrdex or dcrdata, or the harness chain tarball or the code or both? I'm not really sure what changes need to be made to ensure a wire.MsgBlock returns the right hash. Although for the dcrdata UI I appreciate that we'll want to show both the unchanged chainhash (blake256r14) and the pow hash (blake3) if it applies to the block.

EDIT: I recall now that chainhash is the same, only the pow hash is different.

[davecgh]

The harness tarball was regenerated, yes. Regarding the hash function change and the diff algo, are you referring to dcrdex or dcrdata, or the harness chain tarball or the code or both? I'm not really sure what changes need to be made to ensure a wire.MsgBlock returns the right hash.

I was referring to to the dcrdex simnet harness. I'm pretty sure when you regenerated it, it was with the new subsidy, but prior to the code that did the new blake3 pow landing. I'd have to grab the tarball and look to see, but an easy way to tell is just to fire up the simnet harness, invalidate some blocks, and then reconsider them. If it rejects them, it needs to be regenerated.

Although for the dcrdata UI I appreciate that we'll want to show both the unchanged chainhash (blake3) and the pow hash (blake3) if it applies to the block.

EDIT: I recall now that chainhash is the same, only the pow hash is different.

Right, the block hash is still blake256r14 (as opposed to the blake3 you put there, but I imagine that was just a typo based on the context of the rest of the statement). The pow hash is then either blake256 prior to the agenda activation or blake3 once it activates. On simnet, it's always active though, so putting it all together for simnet as of the v1.8.0 release, the block hash is blake256 and the pow hash is blake3.

[chappjc]

I was referring to to the dcrdex simnet harness. I'm pretty sure when you regenerated it, it was with the new subsidy, but prior to the code that did the new blake3 pow landing. I'd have to grab the tarball and look to see, but an easy way to tell is just to fire up the simnet harness, invalidate some blocks, and then reconsider them. If it rejects them, it needs to be regenerated.

yup, you're right

$  ./alpha invalidateblock 36a280f2f22a66520b0bb8bd5d4a63a3f0fdd04bcf1f1b6b03c05090b6fc955c
$  ./alpha reconsiderblock 36a280f2f22a66520b0bb8bd5d4a63a3f0fdd04bcf1f1b6b03c05090b6fc955c
-50: Reconsidering block 36a280f2f22a66520b0bb8bd5d4a63a3f0fdd04bcf1f1b6b03c05090b6fc955c led to one or more validation failures: proof of work hash bc1fedcf05ac64e33e86df9c12d36edd5e540c227cbe20fb62fcc22ba3bda2b6 is higher than expected max of 7fffff0000000000000000000000000000000000000000000000000000000000