This code is inspired by
https://github.com/PirateNetwork/pirate/commit/db292a49ddc13374f43b8c16217e171316be53d7
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.
Run-time asserts are a horrible anti-pattern littered across code
inherited from BTC. One could maybe argue they are the right thing to do
in some situations but not when managing the peer database. Crashing our
full node and potentially corrupting our wallet or block index is INSANE
in the case of some inconsistencies in peers.dat .
We seem to have a bug that we don't find a peer when looking for a peer
in peers.dat . Instead of doing an assertion and crashing the node,
just keep iterating in the loop. The code which computes nId may have an
off-by-one error, such that it looks up an incorrect bucket position and
doesn't find a valid nId.
Duke