DoS transactions params

[tearodactyl]

Parameters on transactions, blocks, mempool that could prevent or mitigate DoS or lockups under heavy load scenarios. Which of these require consensus changes is TBD.

1. Tracking of the state of DoS
   main.cpp: const int dosLevel,

2. Max Transaction size, increased from the Bitcoin value of 100,000 Raise 100kB transaction size limit from Sapling activation zcash/zcash#3212:

consensus.h:
static const unsigned int MAX_BLOCK_SIZE = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = 40000;
/** The maximum size of a transaction (network rule) */
static const unsigned int MAX_TX_SIZE_BEFORE_SAPLING = 100000;
static const unsigned int MAX_TX_SIZE_AFTER_SAPLING = MAX_BLOCK_SIZE;

This should affect transactions being accepted into the mempool, not only a consensus rule. Mempool should not attempt to store more than say 100,000 pending transactions, maybe even much fewer, but do need an efficient data structure to timeout and purge. Could even keep history of rejected or purged transactions to prevent re-introduction zcash#2414

Separately, Bitcoin considered a cache to recognize transactions that have already been validated https://news.bitcoin.com/new-bitcoin-cachin-features-could-improve-block-verification/

3. Timing out transactions from the mempool. Bitcoin was 72 hours, now 7 days, which seems way way high bitcoin/bitcoin@5f0e27f
   Zcash possibly did not have a timeout initially, but after Overwinter uses block height based tracking, 20 2.5 min blocks (50 min). Transaction expiry height zcash/zcash#2874
   Seems like a very large change.
   main.h: static const unsigned int DEFAULT_TX_EXPIRY_DELTA = 20;
   Zero would be like 40 min, which is a bit short during network congestion, etc. Maybe several hours? Block height tracking is best for consensus, but wall time tracking is better for the node health, like with Bitcoin.

4. Alert system retirement Denial of Service via alert subsystem zcash/zcash#3367

5. Ban score and node disconnect logic - could use a more sophisticated system Kick-on-Ban zcash/zcash#2512
   Possibly use configurable white and black listing
   Track IP addresses and even subnets, maybe even geolocation Only allow one connection from a given IP address zcash/zcash#3757

6. UTXO selection algo defaults to use-up smallest amounts first zcash@0afd368#diff-63ec75bfb71c2d4e26f2a95d5168f5e5R795
   That leads to unusable (effectively locked-up) wallets with addresses that accumulated too many spam or small (i.e. coinbase) transactions. Was noted to Zcash Change transparent input selection to avoid excessive number of inputs zcash/zcash#2411
   Patch pending Speed up coin selection by pre-selecting only as many UTXOs as we need zcash/zcash#2819

7. Min transaction fees to make spam leading to DoS more expensive. Ecosystem-wide standard transaction fee zcash/zcash#2942
   Current 0.0001 value is too small for Zero, and should be more like 0.01. That would be fine even when ZER becomes a $1 coin, but can adapt in future releases.

[tearodactyl]

Zcash inherited from Bitcoin a concern about quadratic scaling of hashing. https://bitcoinclassic.com/devel/Quadratic%20Hashing.html
A fix for malleability (without Segwit) may address this https://bitcoinclassic.com/devel/Flexible%20Transactions.html

[daira]

Zcash fixed the quadratic scaling problem in the Overwinter upgrade, btw.

[daira]

Re: point 6, it's not the case that choosing smallest inputs first leads to locked up wallets or too many transactions. That's probably not the optimal strategy, but (since the quadratic hashing fix), it's primarily an issue for short-term performance of creating transactions, not for its effects on long-term wallet performance.

[tearodactyl]

2. Bitcoin did not put a limit on max TX size of 100,000 bytes as a consensus rule, but instead it is a 'standard' for handling transaction relay and mining in a block. The definition was in main.h, till it was moved to policy/policy.h in Bitcoin Core 0.12.0:

/** The maximum size for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_SIZE = 100000;

In Bitcoin 0.13.0 (Q3 2016) and related to Segwit calculations, the variable was renamed and increased (still the same as of Q4 2018 Bitcoin 0.17.1):
static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000;
Famously, several blocks with transactions of almost 1MB were intentionally mined by F2Pool in July 2015, to consolidate dust sent to several famous addresses, plus dozens with weak private keys, like "sex" or "blockchain".

In their finite wisdom, Bitcoin ABC has made the max TX size 1MB, but with max 32MB blocks, in consensus/consensus.h.
static const uint64_t MAX_TX_SIZE = ONE_MEGABYTE;
My understanding is that several months prior to Zcash mainnet launch (Q3 2016), a decision was made zcash#1475, out of concern for Bitcoin quadratic hashing flaw. to adopt the old Bitcoin 100K byte max TX limit, but moreover making it a consensus rule zcash#1501.

With Overwinter addressing zcash#2864 the quadratic hashing zcash#2896 and Sapling timeline approaching zcash#3212, time came to increase the 100K limit, but unfortunately the change went too far but apparently stayed a consensus rule.

/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 2000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = 20000;
/** The maximum size of a transaction (network rule) */
static const unsigned int MAX_TX_SIZE_BEFORE_SAPLING = 100000;
static const unsigned int MAX_TX_SIZE_AFTER_SAPLING = MAX_BLOCK_SIZE;

Bitcoin's 400K could have been a possible choice, perhaps even 1MB, since it worked for Bitcoin and clones. But the entire Zcash block of 2MB for a single transaction has several issues, and most urgent one is that enforcing smaller transaction size allows more transactions mined per block, making transaction-based DoS attacks less overwhelming and more expensive to maintain over time,

Transaction fees is a powerful mechanism for preventing 'transaction spam'. For example, the total today of transaction fees paid on the Bitcoin network was 62 BTC, an amount that few can spend frivolously. Unfortunately, Zcash does not employ Bitcoin-style 'toshi/byte fee structure and charges a nominal per-transaction fee of 0.0001 ZEC instead. As demonstrated, this is only $0.006, and if one transaction can tie up a whole block, and Zcash targets 576 blocks / day, the total of daily fees would be only a few dollars.

I would offer that today there is no incontrovertible proof that the increase in the maximum transaction size above 100K bytes is strictly necessary for the main Sapling use cases, or perhaps 200K would suffice. Then again, there could have been transactions much bigger than that already mined on some chains, and for legit reasons. Regardless, even if a minimum of 20 transactions/block is enforced, the total daily cost of transaction fees would not be a firm deterrent at some $60, so the fees have to go up. Today common BTC transactions pay $0.50-$1.00 and ETH around $0.20-0.50. Until a more elaborate scheme can be investigated, a 10X increase of the default fee, to 0.001 ZEC (under 6 cents today) would help quite a bit.

Best part is that while figuring out how to fork the changes of MAX_TX_SIZE_AFTER_SAPLING and the default fee, we can immediately roll a voluntary full node release with the wallet using the 10X fee, Then alert the miners to give lots of priority to regular-sized transactions with that high of a fee (which they should optimize for already). That will force a potential attacker to match or exceed this rate, to even attempt to flood all blocks. Further, each node can immediately take the original Bitcoin 'standard' approach of dropping incoming transactions above the target size (and consequently not mining or propagating them), but still accepting blocks with such transactions (till a consensus hard fork). This will assure that legit transactions will get through eventually and get mined, making the whole attack pointless.