From ec7d7928f1d77d75a2fc46a22cb7b3d91042bb74 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 23 Dec 2020 02:50:55 +0000 Subject: [PATCH] ZIP 401: reduce threshold for low_fee_penalty to match the new conventional fee specified in ZIP 313. Signed-off-by: Daira Hopwood --- zip-0401.html | 18 +++++++++++++----- zip-0401.rst | 6 ++++-- 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/zip-0401.html b/zip-0401.html index d5440532..42e0b48b 100644 --- a/zip-0401.html +++ b/zip-0401.html @@ -21,7 +21,7 @@ License: MIT

Motivation

Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.

-

Bitcoin Core added size limitation for the mempool in version 0.12 3, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.

+

Bitcoin Core added size limitation for the mempool in version 0.12 4, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.

Requirements

The memory usage of a node’s mempool should be bounded.

@@ -39,7 +39,7 @@ License: MIT

max(serialized transaction size in bytes, 4000)

-

Each transaction also has an eviction weight, which is cost + low_fee_penalty, where low_fee_penalty is 16000 if the transaction pays a fee less than 10000 zatoshi, otherwise 0.

+

Each transaction also has an eviction weight, which is cost + low_fee_penalty, where low_fee_penalty is 16000 if the transaction pays a fee less than the conventional fee, otherwise 0. The conventional fee is currently defined as 1000 zatoshis 3.

Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the given txid was evicted. This SHOULD be empty on node startup. The size of RecentlyEvicted SHOULD never exceed eviction_memory_entries entries, which is the constant 40000.

There MUST be a configuration option mempooltxcostlimit, which SHOULD default to 80000000.

There MUST be a configuration option mempoolevictionmemoryminutes, which SHOULD default to 60.

@@ -59,9 +59,9 @@ License: MIT

Rationale

The accounting for transaction size should include some overhead per transaction, to reflect the cost to the network of processing them (proof and signature verification; networking overheads; size of in-memory data structures). The implication of not including overhead is that a denial-of-service attacker would be likely to use minimum-size transactions so that more of them would fit in a block, increasing the unaccounted-for overhead. A possible counterargument would be that the complexity of accounting for this overhead is unwarranted given that the format of a transaction already imposes a minimum size. However, the proposed cost function is almost as simple as using transaction size directly.

The threshold 4000 for the cost function is chosen so that the size in bytes of a typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up to 5 shielded inputs) will fall below the threshold. This has the effect of ensuring that such transactions are not evicted preferentially to typical transparent transactions because of their size.

-

The proposed eviction policy differs significantly from that of Bitcoin Core 3, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).

+

The proposed eviction policy differs significantly from that of Bitcoin Core 4, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).

The fee penalty is not included in the cost that determines whether the mempool is considered full. This ensures that a DoS attacker does not have an incentive to pay less than the standard fee in order to cause the mempool to be considered full sooner.

-

The default value of 80000000 for mempooltxcostlimit represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade 2. It would serve no purpose to make it larger.

+

The default value of 80000000 for mempooltxcostlimit represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade 2. It would serve no purpose to make it larger.

The mempooltxcostlimit is a per-node configurable parameter in order to provide flexibility for node operators to change it either in response to attempted denial-of-service attacks, or if needed to handle spikes in transaction demand. It may also be useful for nodes running in memory-constrained environments to reduce this parameter.

The limit of eviction_memory_entries = 40000 entries in RecentlyEvicted bounds the memory needed for this data structure. Since a txid is 32 bytes and a timestamp 8 bytes, 40000 entries can be stored in ~1.6 MB, which is small compared to other node memory usage (in particular, small compared to the maximum memory usage of the mempool itself under the default mempooltxcostlimit). eviction_memory_entries entries should be sufficient to mitigate any performance loss caused by re-accepting transactions that were previously evicted. In particular, since a transaction has a minimum cost of 4000, and the default mempooltxcostlimit is 80000000, at most 20000 transactions can be in the mempool of a node using the default parameters. While the number of transactions “in flight” or across the mempools of all nodes in the network could exceed this number, we believe that is unlikely to be a problem in practice.

Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.

@@ -93,10 +93,18 @@ License: MIT - +
+ + + +
3ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis
+ + + + diff --git a/zip-0401.rst b/zip-0401.rst index aaac0327..815cf6c1 100644 --- a/zip-0401.rst +++ b/zip-0401.rst @@ -82,8 +82,9 @@ which is an integer defined as: max(serialized transaction size in bytes, 4000) Each transaction also has an *eviction weight*, which is *cost* + *low_fee_penalty*, -where *low_fee_penalty* is 16000 if the transaction pays a fee less than -10000 zatoshi, otherwise 0. +where *low_fee_penalty* is 16000 if the transaction pays a fee less than the +conventional fee, otherwise 0. The conventional fee is currently defined as +1000 zatoshis [#zip-0313]_. Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the given txid was evicted. This SHOULD be empty on node @@ -204,4 +205,5 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ +.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis `_ .. [#BitcoinCore-PR6722] `Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it `_
4 Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it