2022-09-20 02:12:40 -07:00
|
|
|
::
|
|
|
|
|
|
|
|
ZIP: 317
|
|
|
|
Title: Proportional Transfer Fee Mechanism
|
|
|
|
Owners: Aditya Bharadwaj <nighthawk24@gmail.com>
|
2022-12-05 11:53:28 -08:00
|
|
|
Daira Hopwood <daira@electriccoin.co>
|
2022-09-20 02:12:40 -07:00
|
|
|
Credits: Madars Virza
|
|
|
|
Kris Nuttycombe
|
|
|
|
Jack Grigg
|
|
|
|
Francisco Gindre
|
2022-10-04 14:17:04 -07:00
|
|
|
Status: Draft
|
2022-09-20 02:12:40 -07:00
|
|
|
Category: Standards / Wallet
|
2022-10-04 14:17:04 -07:00
|
|
|
Obsoletes: ZIP 313
|
2022-09-20 02:12:40 -07:00
|
|
|
Created: 2022-08-15
|
|
|
|
License: MIT
|
|
|
|
Discussions-To: <https://forum.zcashcommunity.com/t/zip-proportional-output-fee-mechanism-pofm/42808>
|
|
|
|
Pull-Request: <https://github.com/zcash/zips/pull/631>
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
Terminology
|
|
|
|
===========
|
|
|
|
|
2022-11-09 14:18:52 -08:00
|
|
|
The key words "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document
|
|
|
|
are to be interpreted as described in RFC 2119. [#RFC2119]_
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
The term "conventional transaction fee" in this document is in reference
|
|
|
|
to the value of a transaction fee that is conventionally used by wallets,
|
|
|
|
and that a user can reasonably expect miners on the Zcash network to accept
|
|
|
|
for including a transaction in a block.
|
|
|
|
|
|
|
|
The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined
|
|
|
|
as in [#protocol-networks]_.
|
|
|
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
========
|
|
|
|
|
|
|
|
The goal of this ZIP is to change the conventional fees for transactions
|
2022-10-10 15:18:13 -07:00
|
|
|
by making them dependent on the number of inputs and outputs in a transaction,
|
|
|
|
and to get buy-in for this change from wallet developers, miners and Zcash users.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
==========
|
|
|
|
|
2022-10-10 14:19:43 -07:00
|
|
|
In light of recent Mainnet network activity, it is time to review and update
|
|
|
|
the standard 1,000 zatoshi transaction fee set in ZIP 313 [#zip-0313]_.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as
|
|
|
|
specified in ZIP 313. This allowed exploration of novel use cases of the Zcash
|
|
|
|
blockchain. The Zcash network has operated for almost 2 years at a conventional
|
|
|
|
transaction fee of 1,000 zatoshis, without consideration for the total number
|
|
|
|
of inputs and outputs in each transaction. Under this conventional fee, some
|
|
|
|
usage of the chain has been characterized by high-output transactions with
|
2022-10-10 14:19:43 -07:00
|
|
|
1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
The objective of the new fee policy, once it is enforced, is for fees paid by
|
2022-10-10 14:19:43 -07:00
|
|
|
transactions to fairly reflect the processing costs that their inputs and outputs
|
|
|
|
impose on various participants in the network. This will tend to discourage
|
|
|
|
usage patterns that cause either intentional or unintentional denial of service,
|
|
|
|
while still allowing low fees for regular transaction use cases.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
Requirements
|
|
|
|
============
|
|
|
|
|
|
|
|
* The conventional fee formula should not favour or discriminate against any
|
|
|
|
of the Orchard, Sapling, or transparent protocols.
|
|
|
|
* The fee for a transaction should scale linearly with the number of inputs
|
|
|
|
and/or outputs.
|
|
|
|
* Users should not be penalised for sending transactions constructed
|
|
|
|
with padding of inputs and outputs to reduce information leakage.
|
|
|
|
(The default policy employed by zcashd and the mobile SDKs pads to
|
2022-10-10 14:19:43 -07:00
|
|
|
two inputs and two outputs for each shielded pool used by the transaction).
|
2022-10-04 14:17:04 -07:00
|
|
|
* Users should be able to spend a small number of UTXOs or notes with value
|
|
|
|
below the marginal fee per input.
|
|
|
|
|
|
|
|
|
|
|
|
Specification
|
|
|
|
=============
|
|
|
|
|
2022-10-10 14:03:17 -07:00
|
|
|
Notation
|
|
|
|
--------
|
|
|
|
|
|
|
|
Let :math:`\mathsf{max}(a, b)` be the greater of :math:`a` and :math:`b`.
|
|
|
|
Let :math:`\mathsf{ceiling}(x)` be the smallest integer :math:`\geq x`.
|
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Fee calculation
|
|
|
|
---------------
|
|
|
|
|
2022-10-10 14:03:17 -07:00
|
|
|
This specification defines several parameters that are used to calculate the
|
2022-10-04 14:17:04 -07:00
|
|
|
conventional fee:
|
|
|
|
|
2022-11-29 10:11:50 -08:00
|
|
|
===================================== ============= ==============================================
|
|
|
|
Parameter Value Units
|
|
|
|
===================================== ============= ==============================================
|
|
|
|
:math:`marginal\_fee` :math:`5000` zatoshis per logical action (as defined below)
|
|
|
|
:math:`grace\_actions` :math:`2` logical actions
|
|
|
|
:math:`p2pkh\_standard\_input\_size` :math:`150` bytes
|
|
|
|
:math:`p2pkh\_standard\_output\_size` :math:`34` bytes
|
|
|
|
===================================== ============= ==============================================
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
Wallets implementing this specification SHOULD use a conventional fee
|
2022-10-04 15:57:01 -07:00
|
|
|
calculated in zatoshis per the following formula:
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
.. math::
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
\begin{array}{rcl}
|
2022-10-10 14:03:17 -07:00
|
|
|
logical\_actions &=& \mathsf{max}\big(\mathsf{ceiling}\big(\frac{tx\_in\_total\_size}{p2pkh\_standard\_input\_size}\big),
|
|
|
|
\mathsf{ceiling}\big(\frac{tx\_out\_total\_size}{p2pkh\_standard\_output\_size}\big)\big) \;+ \\
|
2022-10-12 15:01:51 -07:00
|
|
|
& & 2 \cdot nJoinSplit \;+ \\
|
2022-10-10 14:03:17 -07:00
|
|
|
& & \mathsf{max}(nSpendsSapling, nOutputsSapling) \;+ \\
|
|
|
|
& & nActionsOrchard \\
|
|
|
|
conventional\_fee &=& marginal\_fee \cdot \mathsf{max}(grace\_actions, logical\_actions)
|
2022-10-04 15:57:01 -07:00
|
|
|
\end{array}
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-10 14:03:17 -07:00
|
|
|
The inputs to this formula are taken from transaction fields defined in the Zcash protocol
|
2022-10-12 15:01:51 -07:00
|
|
|
specification [#protocol-txnencoding]_:
|
2022-10-10 14:03:17 -07:00
|
|
|
|
|
|
|
============================ ====== ===========================================
|
|
|
|
Input Units Description
|
|
|
|
============================ ====== ===========================================
|
|
|
|
:math:`tx\_in\_total\_size` bytes total size in bytes of the ``tx_in`` field
|
|
|
|
:math:`tx\_out\_total\_size` bytes total size in bytes of the ``tx_out`` field
|
|
|
|
:math:`nJoinSplit` number the number of Sprout JoinSplits
|
|
|
|
:math:`nSpendsSapling` number the number of Sapling spends
|
|
|
|
:math:`nOutputsSapling` number the number of Sapling outputs
|
|
|
|
:math:`nActionsOrchard` number the number of Orchard actions
|
|
|
|
============================ ====== ===========================================
|
|
|
|
|
2022-10-04 14:17:04 -07:00
|
|
|
It is not a consensus requirement that fees follow this formula; however,
|
|
|
|
wallets SHOULD create transactions that pay this fee, in order to reduce
|
|
|
|
information leakage, unless overridden by the user.
|
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Rationale for logical actions
|
|
|
|
'''''''''''''''''''''''''''''
|
|
|
|
|
|
|
|
The intention is to make the fee paid for a transaction depend on its
|
|
|
|
impact on the network, without discriminating between different protocols
|
|
|
|
(Orchard, Sapling, or transparent). The impact on the network depends on
|
|
|
|
the numbers of inputs and outputs.
|
|
|
|
|
|
|
|
A previous proposal used :math:`inputs + outputs` instead of logical actions.
|
2022-10-10 14:19:43 -07:00
|
|
|
This would have disadvantaged Orchard transactions, as a result of an
|
2022-10-04 15:57:01 -07:00
|
|
|
Orchard Action combining an input and an output. The effect of this
|
|
|
|
combining is that Orchard requires padding of either inputs or outputs
|
|
|
|
to ensure that the number of inputs and outputs are the same. Usage of
|
|
|
|
Sapling and transparent protocols does not require this padding, and
|
|
|
|
so this could have effectively discriminated against Orchard.
|
|
|
|
|
|
|
|
Rationale for the chosen parameters
|
|
|
|
'''''''''''''''''''''''''''''''''''
|
|
|
|
|
|
|
|
Grace Actions
|
|
|
|
~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
**Why not just charge per-action, without a grace window?**
|
|
|
|
|
|
|
|
* This ensures that there is no penalty to padding a 1-action
|
|
|
|
transaction to a 2-action transaction. Such padding is desirable
|
|
|
|
to reduce information leakage from input and output arity, and
|
|
|
|
is the standard approach used by `zcashd` and the mobile SDK
|
|
|
|
transaction builder.
|
|
|
|
* Without a grace window, an input with value below the marginal
|
|
|
|
fee would never be worth including in the resulting transaction.
|
|
|
|
With a grace window, an input with value below :math:`marginal\_fee`
|
|
|
|
*is* worth including, if a second input is available that covers
|
|
|
|
both the primary output amount and the conventional transaction
|
|
|
|
fee.
|
|
|
|
|
|
|
|
**Why a grace window of 2?**
|
|
|
|
|
|
|
|
A 1-in, 2-out (or 2-action) transaction is the smallest possible
|
|
|
|
transaction that permits both an output to a recipient, and a
|
|
|
|
change output. However, as stated above, `zcashd` and the mobile
|
|
|
|
SDK transaction builder will pad the number of inputs to at least 2.
|
|
|
|
|
|
|
|
Let :math:`min\_actions` be the minimum number of logical actions
|
|
|
|
that can be used to execute economically relevant transactions that
|
|
|
|
produce change. Due to the aforementioned padding, :math:`min\_actions = 2`.
|
|
|
|
|
|
|
|
Having a grace window size greater than :math:`min\_actions` would
|
|
|
|
increase the cost to create such a minimal transaction. If the
|
2022-10-10 14:19:43 -07:00
|
|
|
cost we believe that users will tolerate for a minimal transaction
|
|
|
|
is :math:`B`, then possible choices of :math:`marginal\_fee` are
|
|
|
|
bounded above by :math:`B / \max(min\_actions, grace\_actions)`.
|
|
|
|
Therefore, the optimal choice of :math:`grace\_actions` to maximize
|
|
|
|
the per-logical-action cost of denial-of-service attacks for a given
|
|
|
|
:math:`B`, is :math:`grace\_actions = min\_actions = 2`. This also
|
|
|
|
ensures that a denial-of-service adversary does not gain a
|
|
|
|
significant per-logical-action cost advantage by using transactions
|
|
|
|
with a smaller or larger number of logical actions.
|
2022-10-04 15:57:01 -07:00
|
|
|
|
2022-10-12 07:00:15 -07:00
|
|
|
Transparent Contribution
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
The specified formula calculates the contribution of transparent inputs
|
|
|
|
and outputs based on their total size relative to a typical input or
|
|
|
|
output. Another considered approach was to calculate this contribution
|
|
|
|
simply as :math:`\mathsf{max}(transparent\_inputs, transparent\_outputs)`.
|
|
|
|
However, this would allow a denial-of-service adversary to create
|
|
|
|
transactions with transparent components containing arbitrarily large
|
|
|
|
scripts.
|
|
|
|
|
|
|
|
The chosen values for :math:`p2pkh\_standard\_input\_size` and
|
|
|
|
:math:`p2pkh\_standard\_output\_size` are based on the maximum encoded
|
2022-10-12 15:01:51 -07:00
|
|
|
length for P2PKH inputs and outputs, as follows:
|
2022-10-12 07:00:15 -07:00
|
|
|
|
|
|
|
* :math:`p2pkh\_standard\_input\_size`
|
|
|
|
|
|
|
|
* outpoint: 36 bytes
|
2022-10-12 15:01:51 -07:00
|
|
|
* script: 110 bytes
|
|
|
|
|
|
|
|
* 1 (overall length) + 1 (signature length) + 72 (signature) + 1 (sighash type) + 1 (pubkey length) + 33 (pubkey) + 1 (margin)
|
|
|
|
|
2022-10-12 07:00:15 -07:00
|
|
|
* sequence: 4 bytes
|
|
|
|
|
|
|
|
* :math:`p2pkh\_standard\_output\_size`
|
|
|
|
|
|
|
|
* value: 8 bytes
|
|
|
|
* script: 26 bytes
|
|
|
|
|
2022-10-12 15:01:51 -07:00
|
|
|
* 1 (script length) + 25 (P2PKH script)
|
|
|
|
|
|
|
|
P2SH outputs are smaller than P2PKH outputs, but P2SH inputs
|
|
|
|
may be larger than P2PKH inputs. For example a 2-of-3 multisig
|
|
|
|
input is around 70% larger, and is counted as such when computing
|
|
|
|
the number of logical actions.
|
2022-10-12 07:00:15 -07:00
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Marginal Fee
|
|
|
|
~~~~~~~~~~~~
|
|
|
|
|
|
|
|
This returns the conventional fee for a minimal transaction (as
|
|
|
|
described above) to the original conventional fee of 10000 zatoshis
|
|
|
|
specified in [#zip-0313]_, and imposes a non-trivial cost for
|
|
|
|
potential denial-of-service attacks.
|
|
|
|
|
2022-10-04 14:17:04 -07:00
|
|
|
Transaction relaying
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
zcashd, zebrad, and potentially other node implementations, implement
|
|
|
|
fee-based restrictions on relaying of mempool transactions. Nodes that
|
|
|
|
normally relay transactions are expected to do so for transactions that pay
|
|
|
|
at least the conventional fee as specified in this ZIP, unless there are
|
|
|
|
other reasons not to do so for robustness or denial-of-service mitigation.
|
|
|
|
|
|
|
|
Mempool size limiting
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
zcashd and zebrad limit the size of the mempool as described in [#zip-0401]_.
|
2022-10-04 15:57:01 -07:00
|
|
|
This specifies a :math:`low\_fee\_penalty` that is added to the "eviction weight"
|
2022-10-04 14:17:04 -07:00
|
|
|
if the transaction pays a fee less than the conventional transaction fee.
|
|
|
|
This threshold is modified to use the new conventional fee formula.
|
|
|
|
|
|
|
|
Block production
|
|
|
|
----------------
|
|
|
|
|
|
|
|
Miners, mining pools, and other block producers, select transactions for
|
2022-11-09 14:18:52 -08:00
|
|
|
inclusion in blocks using a variety of criteria. The algorithm in the
|
|
|
|
following section is planned to be implemented by `zcashd` and `zebrad`.
|
|
|
|
|
|
|
|
Recommended algorithm for block template construction
|
|
|
|
'''''''''''''''''''''''''''''''''''''''''''''''''''''
|
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
Define constants :math:`weight\_ratio\_cap = 4` and
|
|
|
|
:math:`block\_unpaid\_action\_limit = 50\!`.
|
2022-11-09 14:18:52 -08:00
|
|
|
|
|
|
|
Let :math:`conventional\_fee(tx)` be the conventional fee for transaction
|
|
|
|
:math:`tx` calculated according to the section `Fee calculation`_.
|
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
Let :math:`unpaid\_actions(tx) = \mathsf{max}\!\left(0,\, \mathsf{max}(grace\_actions,\, tx.\!logical\_actions) - \mathsf{floor}\!\left(\frac{tx.fee}{marginal\_fee}\right)\right)\!`.
|
|
|
|
|
|
|
|
Let :math:`block\_unpaid\_actions(block) = \sum_{tx \,\in\, block}\, unpaid\_actions(tx)`.
|
|
|
|
|
2022-11-09 14:18:52 -08:00
|
|
|
The following algorithm is RECOMMENDED for constructing block templates
|
|
|
|
from a set of transactions in a node's mempool:
|
|
|
|
|
|
|
|
1. For each transaction :math:`tx` in the mempool, calculate
|
2022-11-30 19:00:25 -08:00
|
|
|
:math:`tx.\!weight\_ratio = \mathsf{min}\!\left(\frac{\mathsf{max}(1,\, tx.fee)}{conventional\_fee(tx)},\, weight\_ratio\_cap\right)\!`
|
2022-11-30 17:45:25 -08:00
|
|
|
and add the transaction to the set of candidate transactions.
|
2022-11-09 14:18:52 -08:00
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
2. Repeat while there is any candidate transaction that pays at least the
|
|
|
|
conventional fee:
|
2022-11-09 14:18:52 -08:00
|
|
|
|
|
|
|
a. Pick one of those transactions at random with probability in direct
|
2022-12-01 13:07:41 -08:00
|
|
|
proportion to its :math:`weight\_ratio`, and remove it from the set of
|
|
|
|
candidate transactions. Let :math:`B` be the block template with this
|
|
|
|
transaction included.
|
2022-11-30 17:45:25 -08:00
|
|
|
b. If :math:`B` would be within the block size limit and block sigop
|
|
|
|
limit [#sigop-limit]_, add the transaction to the block template.
|
2022-11-09 14:18:52 -08:00
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
3. Repeat while there is any candidate transaction:
|
2022-11-09 14:18:52 -08:00
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
a. Pick one of those transactions at random with probability in direct
|
2022-12-01 13:07:41 -08:00
|
|
|
proportion to its :math:`weight\_ratio`, and remove it from the set of
|
|
|
|
candidate transactions. Let :math:`B` be the block template with this
|
|
|
|
transaction included.
|
2022-11-30 17:45:25 -08:00
|
|
|
b. If :math:`B` would be within the block size limit and block sigop
|
|
|
|
limit [#sigop-limit]_ and :math:`block\_unpaid\_actions(B) \leq block\_unpaid\_action\_limit\!`,
|
|
|
|
add the transaction to the block template.
|
2022-11-09 14:18:52 -08:00
|
|
|
|
|
|
|
Rationale for block template construction algorithm
|
|
|
|
'''''''''''''''''''''''''''''''''''''''''''''''''''
|
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
It is likely that not all wallets will immediately update to pay the
|
|
|
|
(generally higher) fees specified by this ZIP. In order to be able to deploy
|
|
|
|
this block template algorithm more quickly while still giving transactions
|
|
|
|
created by such wallets a reasonable chance of being mined, we allow a
|
|
|
|
limited number of "unpaid" logical actions in each block. Roughly speaking,
|
|
|
|
if a transaction falls short of paying the conventional transaction fee by
|
|
|
|
:math:`k` times the marginal fee, we count that as :math:`k` unpaid logical
|
|
|
|
actions.
|
|
|
|
|
|
|
|
Regardless of how full the mempool is (according to the ZIP 401 [#zip-0401]_
|
|
|
|
cost limiting), and regardless of what strategy a denial-of-service adversary
|
|
|
|
may use, the number of unpaid logical actions in each block is always limited
|
|
|
|
to at most :math:`block\_unpaid\_action\_limit\!`.
|
|
|
|
|
|
|
|
The weighting in step 2 does not create a situation where the adversary gains
|
|
|
|
a significant advantage over other users by paying more than the conventional
|
|
|
|
fee, for two reasons:
|
|
|
|
|
|
|
|
1. The weight ratio cap limits the relative probability of picking a given
|
|
|
|
transaction to be at most :math:`weight\_ratio\_cap` times greater than a
|
|
|
|
transaction that pays exactly the conventional fee.
|
|
|
|
|
|
|
|
2. Compare the case where the adversary pays :math:`c` times the conventional
|
|
|
|
fee for one transaction, to that where they pay the conventional fee for
|
|
|
|
:math:`c` transactions. In the former case they are more likely to get *each*
|
|
|
|
transaction into the block relative to competing transactions from other users,
|
|
|
|
*but* those transactions take up less block space, all else (e.g. choice of
|
|
|
|
input or output types) being equal. This is not what the attacker wants;
|
|
|
|
they get a transaction into the block only at the expense of leaving more
|
|
|
|
block space for the other users' transactions.
|
|
|
|
|
|
|
|
The rationale for choosing :math:`weight\_ratio\_cap = 4` is as a compromise
|
|
|
|
between not allowing any prioritization of transactions relative to those that
|
|
|
|
pay the conventional fee, and allowing arbitrary prioritization based on ability
|
|
|
|
to pay.
|
2022-11-09 14:18:52 -08:00
|
|
|
|
2022-12-01 13:07:41 -08:00
|
|
|
Calculating :math:`tx.\!weight\_ratio` in terms of :math:`\mathsf{max}(1,\, tx.\!fee)`
|
|
|
|
rather than just :math:`tx.\!fee` avoids needing to define "with probability in direct
|
|
|
|
proportion to its :math:`weight\_ratio\!`" for the case where all remaining candidate
|
|
|
|
transactions would have :math:`weight\_ratio = 0\!`.
|
|
|
|
|
2022-11-09 14:18:52 -08:00
|
|
|
Incentive compatibility for miners
|
|
|
|
''''''''''''''''''''''''''''''''''
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-10 15:18:13 -07:00
|
|
|
Miners have an incentive to make this change because:
|
|
|
|
|
|
|
|
* it will tend to increase the fees they are due;
|
|
|
|
* fees will act as a damping factor on the time needed to process blocks,
|
|
|
|
and therefore on orphan rate.
|
|
|
|
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
Security and Privacy considerations
|
|
|
|
===================================
|
|
|
|
|
|
|
|
Non-standard transaction fees may reveal specific users or wallets or wallet
|
|
|
|
versions, which would reduce privacy for those specific users and the rest
|
2022-10-10 14:19:43 -07:00
|
|
|
of the network. However, the advantage of faster deployment weighed against
|
2022-10-04 14:17:04 -07:00
|
|
|
synchronizing the change in wallet behaviour at a specific block height.
|
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Long term, the issue of fees needs to be revisited in separate future
|
|
|
|
proposals as the blocks start getting consistently full. Wallet developers
|
|
|
|
and operators should monitor the Zcash network for rapid growth in
|
|
|
|
transaction rates, and consider further changes to fee selection and/or
|
|
|
|
other scaling solutions if necessary.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Denial of Service
|
|
|
|
-----------------
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
A transaction-rate-based denial of service attack occurs when an attacker
|
|
|
|
generates enough transactions over a window of time to prevent legitimate
|
|
|
|
transactions from being mined, or to hinder syncing blocks for full nodes
|
|
|
|
or miners.
|
|
|
|
|
|
|
|
There are two primary protections to this kind of attack in Zcash: the
|
|
|
|
block size limit, and transaction fees. The block size limit ensures that
|
|
|
|
full nodes and miners can keep up with the blockchain even if blocks are
|
|
|
|
completely full. However, users sending legitimate transactions may not
|
|
|
|
have their transactions confirmed in a timely manner.
|
|
|
|
|
|
|
|
This proposal does not alter how fees are paid from transactions to miners.
|
|
|
|
|
|
|
|
|
|
|
|
Deployment
|
|
|
|
==========
|
|
|
|
|
|
|
|
Wallets SHOULD deploy these changes immediately. Nodes SHOULD deploy the
|
2022-10-04 15:57:01 -07:00
|
|
|
change to the :math:`low\_fee\_penalty` threshold described in
|
|
|
|
`Mempool size limiting`_ immediately.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
Nodes supporting block template construction SHOULD deploy the new
|
|
|
|
`Recommended algorithm for block template construction`_ immediately,
|
|
|
|
and miners SHOULD use nodes that have been upgraded to this algorithm.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-10 15:18:13 -07:00
|
|
|
Node developers SHOULD coordinate on schedules for deploying restrictions
|
|
|
|
to their policies for transaction mempool acceptance and peer-to-peer
|
|
|
|
relaying. These policy changes SHOULD NOT be deployed before the changes
|
2022-11-30 17:45:25 -08:00
|
|
|
to block template construction for miners described in the preceding
|
2022-10-10 15:18:13 -07:00
|
|
|
paragraph.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
|
|
|
|
Considered Alternatives
|
|
|
|
=======================
|
|
|
|
|
|
|
|
This section describes alternative proposals that have not been adopted.
|
|
|
|
|
2022-10-10 15:18:13 -07:00
|
|
|
In previous iterations of this specification, the marginal fee was multiplied
|
|
|
|
by the sum of inputs and outputs. This means that the alternatives given
|
|
|
|
below are roughly half of what they would be under the current formula.
|
|
|
|
|
2022-10-04 15:57:01 -07:00
|
|
|
Possible alternatives for the parameters:
|
|
|
|
|
2022-11-30 17:45:25 -08:00
|
|
|
* :math:`marginal\_fee = 250` in @nuttycom's proposal.
|
|
|
|
* :math:`marginal\_fee = 1000` adapted from @madars' proposal [#madars-1]_.
|
|
|
|
* :math:`marginal\_fee = 2500` in @daira's proposal.
|
|
|
|
* :math:`marginal\_fee = 1000` for Shielded, Shielding and De-shielding
|
|
|
|
transactions, and :math:`marginal\_fee = 10000` for Transparent transactions
|
2022-10-04 15:57:01 -07:00
|
|
|
adapted from @nighthawk24's proposal.
|
|
|
|
|
|
|
|
(In @madars' and @nighthawk24's original proposals, there was an additional
|
2022-11-30 17:45:25 -08:00
|
|
|
:math:`base\_fee` parameter that caused the relationship between fee and number
|
|
|
|
of inputs/outputs to be non-proportional above the :math:`grace\_actions`
|
|
|
|
threshold. This is no longer expressible with the formula specified above.)
|
2022-10-04 15:57:01 -07:00
|
|
|
|
|
|
|
|
2022-10-04 14:17:04 -07:00
|
|
|
Endorsements
|
|
|
|
============
|
|
|
|
|
|
|
|
The following entities/groups/individuals expressed their support for the
|
|
|
|
updated fee mechanism:
|
|
|
|
|
|
|
|
*Developer Groups or Sole OSS contributors*
|
|
|
|
|
2022-10-10 15:18:13 -07:00
|
|
|
..
|
|
|
|
* Zecwallet Suite (Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode)
|
|
|
|
* Nighthawk Wallet for Android & iOS
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
To express and request your support to be added to this ZIP please comment
|
|
|
|
below indicating:
|
|
|
|
|
|
|
|
* (group) name/pseudonym
|
|
|
|
* affiliation
|
|
|
|
* contact
|
|
|
|
|
|
|
|
or, conversely e-mail the same details to the Owner of the ZIP.
|
|
|
|
|
2022-10-10 15:18:13 -07:00
|
|
|
TODO: Endorsements may depend on specific parameter choices. The ZIP
|
2022-10-12 15:01:51 -07:00
|
|
|
Editors should ensure that the endorsements are accurate before marking
|
|
|
|
this ZIP as Active.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
Acknowledgements
|
|
|
|
================
|
|
|
|
|
|
|
|
Thanks to Madars Virza for initially proposing a fee mechanism similar to that
|
2022-11-30 17:45:25 -08:00
|
|
|
proposed in this ZIP [#madars-1]_, and for finding a potential weakness in an
|
|
|
|
earlier version of the block template construction algorithm. Thanks also to
|
2022-12-05 11:53:28 -08:00
|
|
|
Kris Nuttycombe, Jack Grigg, Francisco Gindre, Greg Pfeil, Teor, and
|
|
|
|
Deirdre Connolly for reviews and suggested improvements.
|
2022-10-04 14:17:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
==========
|
|
|
|
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
|
|
|
.. [#protocol-networks] `Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
2022-10-10 14:03:17 -07:00
|
|
|
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
|
2022-11-09 16:50:52 -08:00
|
|
|
.. [#sigop-limit] `zcash/zips issue #568 - Document block transparent sigops limit consensus rule <https://github.com/zcash/zips/issues/568>`_
|
2022-10-04 14:17:04 -07:00
|
|
|
.. [#madars-1] `Madars concrete soft-fork proposal <https://forum.zcashcommunity.com/t/zip-reduce-default-shielded-transaction-fee-to-1000-zats/37566/89>`_
|
|
|
|
.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis <zip-0313.rst>`_
|
|
|
|
.. [#zip-0401] `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`_
|