mirror of https://github.com/zcash/zips.git
Merge pull request #637 from daira/proportional-fee
ZIP 317: Proportional Transfer Fee Mechanism
This commit is contained in:
commit
f1924784f0
|
@ -141,7 +141,7 @@ Index of ZIPs
|
|||
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323.rst">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Active</td>
|
||||
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402.rst">New Wallet Database Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403.rst">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
|
||||
|
|
303
zip-0317.rst
303
zip-0317.rst
|
@ -8,9 +8,310 @@
|
|||
Daira Hopwood
|
||||
Jack Grigg
|
||||
Francisco Gindre
|
||||
Status: Reserved
|
||||
Status: Draft
|
||||
Category: Standards / Wallet
|
||||
Obsoletes: ZIP 313
|
||||
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>
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key word "SHOULD" in this document is to be interpreted as described in
|
||||
RFC 2119. [#RFC2119]_
|
||||
|
||||
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
|
||||
and get buy-in from wallet developers, miners, and Zcash users.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
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]_.
|
||||
|
||||
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
|
||||
1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.
|
||||
|
||||
The objective of the new fee policy, once it is enforced, is for fees paid by
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
two inputs and two outputs for each shielded pool used by the transaction).
|
||||
* Users should be able to spend a small number of UTXOs or notes with value
|
||||
below the marginal fee per input.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Fee calculation
|
||||
---------------
|
||||
|
||||
This specification defines two parameters that are used to calculate the
|
||||
conventional fee:
|
||||
|
||||
====================== ==============================================
|
||||
Parameter Units
|
||||
====================== ==============================================
|
||||
:math:`marginal\_fee` zatoshis per logical action (as defined below)
|
||||
:math:`grace\_actions` logical actions
|
||||
====================== ==============================================
|
||||
|
||||
Wallets implementing this specification SHOULD use a conventional fee
|
||||
calculated in zatoshis per the following formula:
|
||||
|
||||
.. math::
|
||||
|
||||
\begin{array}{rcl}
|
||||
logical\_actions &=& \max(transparent\_inputs, transparent\_outputs) \;+ \\
|
||||
& & 2 \cdot sprout\_joinsplits \;+ \\
|
||||
& & \max(sapling\_inputs, sapling\_outputs) \;+ \\
|
||||
& & orchard\_actions \\
|
||||
conventional\_fee &=& marginal\_fee \cdot \max(grace\_actions, logical\_actions)
|
||||
\end{array}
|
||||
|
||||
The parameters are set to the following values:
|
||||
|
||||
* :math:`marginal\_fee = 5000`;
|
||||
* :math:`grace\_actions = 2`.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
This would have disadvantaged Orchard transactions, as a result of an
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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]_.
|
||||
This specifies a :math:`low\_fee\_penalty` that is added to the "eviction weight"
|
||||
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
|
||||
inclusion in blocks using a variety of criteria. Where the criteria
|
||||
previously used the conventional transaction fee defined in ZIP 313 to
|
||||
decide on transaction inclusion, it is expected to instead use the formula
|
||||
specified in this ZIP.
|
||||
|
||||
|
||||
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
|
||||
of the network. However, the advantage of faster deployment weighed against
|
||||
synchronizing the change in wallet behaviour at a specific block height.
|
||||
|
||||
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.
|
||||
|
||||
Denial of Service
|
||||
-----------------
|
||||
|
||||
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
|
||||
change to the :math:`low\_fee\_penalty` threshold described in
|
||||
`Mempool size limiting`_ immediately.
|
||||
|
||||
Nodes can deploy restrictions to their policies for relaying, mempool
|
||||
acceptance, and/or mining once a sufficient proportion of wallets in the
|
||||
ecosystem are observed to be paying at least the updated conventional
|
||||
transaction fee. Node developers SHOULD coordinate on deployment
|
||||
schedule.
|
||||
|
||||
|
||||
|
||||
Considered Alternatives
|
||||
=======================
|
||||
|
||||
This section describes alternative proposals that have not been adopted.
|
||||
|
||||
Possible alternatives for the parameters:
|
||||
|
||||
* marginal_fee = 250 in @nuttycom's proposal.
|
||||
* marginal_fee = 1000 adapted from @madars' proposal.
|
||||
* marginal_fee = 2500 in @daira's proposal.
|
||||
* marginal_fee = 1000 for Shielded, Shielding and De-shielding
|
||||
transactions, and marginal_fee = 10000 for Transparent transactions
|
||||
adapted from @nighthawk24's proposal.
|
||||
|
||||
(In @madars' and @nighthawk24's original proposals, there was an additional
|
||||
`base_fee` parameter that caused the relationship between fee and number
|
||||
of inputs/outputs to be non-proportional above the `grace_window_size`. This
|
||||
is no longer expressible with the formula specified above.)
|
||||
|
||||
|
||||
|
||||
Endorsements
|
||||
============
|
||||
|
||||
The following entities/groups/individuals expressed their support for the
|
||||
updated fee mechanism:
|
||||
|
||||
*Developer Groups or Sole OSS contributors*
|
||||
|
||||
* Zecwallet Suite (Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode)
|
||||
* Nighthawk Wallet for Android & iOS
|
||||
|
||||
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.
|
||||
|
||||
> TODO: Endorsements may depend on specific parameter choices. The ZIP
|
||||
> Editors should ensure that the endorsements are accurate before merging
|
||||
> this ZIP.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
||||
Thanks to Madars Virza for initially proposing a fee mechanism similar to that
|
||||
proposed in this ZIP [#madars-1]_, and to Kris Nuttycombe, Jack Grigg, Daira Hopwood,
|
||||
Francisco Gindre, Greg Pfeil, and Teor for suggested improvements.
|
||||
|
||||
|
||||
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>`_
|
||||
.. [#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>`_
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
ZIP: 401
|
||||
Title: Addressing Mempool Denial-of-Service
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Status: Active
|
||||
Category: Network
|
||||
Created: 2019-09-09
|
||||
License: MIT
|
||||
|
@ -83,8 +83,8 @@ which is an integer defined as:
|
|||
|
||||
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 [#zip-0313]_.
|
||||
conventional fee, otherwise 0. The conventional fee is currently defined in
|
||||
[#zip-0317]_.
|
||||
|
||||
Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where
|
||||
the time indicates when the transaction with the given txid was evicted. The txid
|
||||
|
@ -211,5 +211,5 @@ References
|
|||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
||||
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`_
|
||||
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
|
||||
.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis <zip-0313.rst>`_
|
||||
.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism <zip-0317.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>`_
|
||||
|
|
Loading…
Reference in New Issue