These NU's are always active for Hush Arrakis Chains so this code only serves
to slow down all operations by constantly being checked. So we disable them
which will speed up syncing, mining and creating transactions.
This change lifts the declaration of the randomx VM out of an inner loop
into the main function body of RandomXMiner(), which allows us to destroy
it later on when catching exceptions. We cannot lift the allocation of it's
memory (randomx_create_vm) because it depends on things that change in every
iteration of the inner loop. Otherwise, the VM will only sometimes
be destroyed, which is what I think causes the memleak.
But this seems to create one invalid block when mining each block height :
STDOUT:
TestBlockValidity: failure C checkPOW=1
RandomXMiner: Invalid randomx block mined, try again 05f30f419133b2d862106b89c20059967639e4f2699dd5afc5d2b0832f1ac76a
debug.log:
2023-10-11 16:10:41 CreateNewBlock(): total size 1000 blocktime.1697040642 nBits.200e77d1
2023-10-11 16:10:41 Running HushRandomXMiner with 1 transactions in block (260 bytes)
2023-10-11 16:10:41 ERROR: ContextualCheckBlock: block height mismatch in coinbase
Mining does seem to continue normally when testing with -testnode=1
This code is inspired by
db292a49dd
with various improvements that will be documented below.
The largest improvement is that this code will defend against a spammer using shielded inputs (zins)
or shielded outputs (zouts) while the Pirate code only defends against zout spam.
We wrote a new RPC called z_getstats to study exactly what the distribution of shielded inputs (zins)
and shielded outputs (zouts) look like on HUSH mainnet. Sietch will never make a ztx that contains
more than 9 zouts and so transactions with 10 or more zouts are extremely rare. They correspond to custom
transactions created via code or CLI or mining pool payouts. We allow at most one of these per block. If
there are two, one will remain in the mempool and be mined in the subsequent block. Our code is more strict,
as Pirate will allow up to 6 of these transactions in a single block.
Transactions with many shielded inputs do occur normally when users spend many small shielded unspent outputs
(zutxos) in one transaction, but we determined that a cutoff of 50 zins is quite rare. Between blocks
14000000 and 15000000 only 27 ztxs had 50 or more zins, which is 0.03% . We allow at most one of these
per block and if there are more, they will wait to be mined in a subsequent block.
Also note that a transaction can match both criteria of having large zins and large zouts, so for instance,
if there is a transaction with 50 zins and 10 zouts, it counts towards both requirements and no other
transactions with >=50 zins or >=10 zouts will be mined in that block.
If >=200 transactions with either large zins or large zouts are broadcast to the network it will take at least
200 blocks for them to be mined and so via existing rules for ztx expiration they will expire and be removed
from the mempool, since by default all ztxs expire after 200 blocks. Since normal ztxs that match these
criteria are very rare, the only case when this might happen is during a spam attack and so the attackers
transactions expiring is another part of these defenses.
Other improvements are that we log txids of transactions with large zins or zouts and we do not support a
command line option to turn this protection off. This forces a potential attacker to compile their own custom
code if they want to subvert these protections on their own node and blocks they mine.
Similar to Pirate, these changes are not consensus changes but may be made consensus requirements
in the future.
These protections are not specific to HUSH and are enabled for all HSC's, including DragonX.
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.
