This option can disable automatic resending of txs. It defaults to the
normal behavior of resending txs automatically and resending can be disabled
with -resendtx=0 .
This is not intended for normal usage and is undocumented for now. It is
useful for devs who are debugging internals and also when rescanning large
wallets. We seem to have either some bugs and/or performance problems when
rescanning wallets with many txs.
This is a greatly simplified and slightly tweaked version of
af2e3713e2
Their version will detect duplicate zkproofs across transactions while
this code will only detect duplicate zkproofs in a single ztx. If dupes
are found, the tx will be denied entry into the mempool.
This provides most of the benefit (increased CPU cost to attackers) with the
least code change and no annoyance to full node operators. Detecting
duplicate zkproofs across transactions requires a one-time reindex of
all of history, which means significant downtime for nodes.
Since Hush + HSCs have a much more strict policy on number of shielded
outputs and shielded inputs, only detecting duplicate zkproofs in
individual ztxs seems sufficient for now.
No correctly functioning node or wallet will ever create duplicate
zkproofs, so there is no worry of this accidentally affecting normal
users. Currently this is not a consensus rule but it could become one
in the future.
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.
If we don't, we can get the hilarious error message that the node is Rescanning...
when trying to run abortrescan when the node automatically does a rescan on boot.
duke
Duke
jahway603