zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 401: reduce threshold for low_fee_penalty to match the new conventional fee specified in ZIP 313. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-12-23 02:50:55 +00:00
parent 744aca3136
commit ec7d7928f1
2 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
zip-0401.html
View File

@ -21,7 +21,7 @@ License: MIT</pre>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.</p>
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a id="id2" class="footnote_reference" href="#bitcoincore-pr6722">3</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a id="id2" class="footnote_reference" href="#bitcoincore-pr6722">4</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
</section>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The memory usage of a node’s mempool should be bounded.</p>
@ -39,7 +39,7 @@ License: MIT</pre>
<blockquote>
<p>max(serialized transaction size in bytes, 4000)</p>
</blockquote>
<p>Each transaction also has an <em>eviction weight</em>, which is <em>cost</em> + <em>low_fee_penalty</em>, where <em>low_fee_penalty</em> is 16000 if the transaction pays a fee less than 10000 zatoshi, otherwise 0.</p>
<p>Each transaction also has an <em>eviction weight</em>, which is <em>cost</em> + <em>low_fee_penalty</em>, where <em>low_fee_penalty</em> is 16000 if the transaction pays a fee less than the conventional fee, otherwise 0. The conventional fee is currently defined as 1000 zatoshis <a id="id4" class="footnote_reference" href="#zip-0313">3</a>.</p>
<p>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 <code>eviction_memory_entries</code> entries, which is the constant 40000.</p>
<p>There MUST be a configuration option <code>mempooltxcostlimit</code>, which SHOULD default to 80000000.</p>
<p>There MUST be a configuration option <code>mempoolevictionmemoryminutes</code>, which SHOULD default to 60.</p>
@ -59,9 +59,9 @@ License: MIT</pre>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
<p>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.</p>
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a id="id4" class="footnote_reference" href="#bitcoincore-pr6722">3</a>, 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).</p>
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a id="id5" class="footnote_reference" href="#bitcoincore-pr6722">4</a>, 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).</p>
<p>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.</p>
<p>The default value of 80000000 for <code>mempooltxcostlimit</code> represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade <a id="id5" class="footnote_reference" href="#zip-0208">2</a>. It would serve no purpose to make it larger.</p>
<p>The default value of 80000000 for <code>mempooltxcostlimit</code> represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade <a id="id6" class="footnote_reference" href="#zip-0208">2</a>. It would serve no purpose to make it larger.</p>
<p>The <code>mempooltxcostlimit</code> 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.</p>
<p>The limit of <code>eviction_memory_entries</code> = 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 <code>mempooltxcostlimit</code>). <code>eviction_memory_entries</code> 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 <code>mempooltxcostlimit</code> 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.</p>
<p>Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.</p>
@ -93,10 +93,18 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="bitcoincore-pr6722" class="footnote">
<table id="zip-0313" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0313">ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis</a></td>
</tr>
</tbody>
</table>
<table id="bitcoincore-pr6722" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/bitcoin/bitcoin/pull/6722">Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it</a></td>
</tr>
</tbody>

6
zip-0401.rst
View File

@ -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 <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis <zip-0313.rst>`_
.. [#BitcoinCore-PR6722] `Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it <https://github.com/bitcoin/bitcoin/pull/6722>`_