Replace an assert() in Unserialize() with the actual behavior we want,
i.e. making sure that vRandom is empty. Before the assert() was added,
the code called Clear() which ensured vRandom was empty. Clear() was
changed to the assert() in BTC commit b138973a8b4bbe061ad97011f278a21e08ea79e6
to prevent recursive locks but risks crashing the node. Instead, we
just empty out vRandom.
The addition of EXCLUSIVE_LOCKS_REQUIRED is not needed to fix
this but seems prudent since Serialize() has it and the original code
from BTC has EXCLUSIVE_LOCKS_REQUIRED on all the methods of this class.
As a side note, crashing a full node with an assert() and possibly
corrupting the wallet.dat, block files and other data is REALLY
FUCKING DUMB. Instead, code should be written to prevent the
possibility of crashing or throw an exception with a useful error.
Some comments turned out to be wrong and some could be more helpful.
It turns out that when AveragingWindowTimespan was changed to fix a HUSH
mainnet bug long ago, that introduced a bug for HSC's that do not use
a 75s block time. Since the default is 60s that likely means all HSC's that will
be created. There were no production HSC's in use at the time of that bugfix,
so the bug went unnoticed until DRAGONX was launched. The bug then manifested
as the DRAGONX difficulty bug, which cause the difficulty to never correct down,
only up and lead to extremely long block times on DRAGONX mainnet.
This code change ensures that HUSH mainnet uses the same hardcoded AWT as it
did previously and all other HSC's will use params.AveragingWindowTimespan() ,
including DRAGONX mainnet.
This seems less dangerous than changing AveragingWindowTimespan() on HUSH mainnet.
These code changes move various randomx setup code out of the inner mining loop,
which significantly increases hashrate. Currently seeing ~60 hashes/second/core
on a Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz.
This code may have memory leaks, it does not destroy the randomx VM since it was
causing coredumps. It also seems to use more memory, I am only able to mine on 2
cores with 16GB of RAM. Using more cores runs out of memory.
There was a small bug in getrescaninfo where when a rescan first starts, it
shows rescanning=true but progress=100% because rescanHeight was not initialized
correctly.
Also update our rescanHeight while we are fast-forwarding thru blocks which are
before the current wallet birthday.
