ZIP: 313 Title: Reduce Conventional Transaction Fee to 1000 zatoshis Owners: Aditya Bharadwaj <[email protected]> Credits: Daira-Emma Hopwood Deirdre Connolly Nathan Wilcox Status: Obsolete Obsoleted-By: 317 Category: Wallet Created: 2020-10-11 License: MIT Discussions-To: <https://forum.zcashcommunity.com/t/zip-reduce-default-shielded-transaction-fee-to-1000-zats/37566> Pull-Request: <https://github.com/zcash/zips/pull/408>
The key words "SHOULD" and "RECOMMENDED" in this document are to be interpreted as described in BCP 14 [1] when, and only when, they appear in all capitals.
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 goal of this ZIP is to gather wallet developers, miners & Zcash users for social consensus on reducing the conventional transaction fees and to get the Zcash conventional transaction fee reduced from 10,000 zatoshis to 1,000 zatoshis.
In addition, this specification harmonizes transaction fees between different kinds of transaction (involving shielded addresses, transparent addresses, or both), as proposed in [7].
Warning
This ZIP has been obsoleted by ZIP 317 [9]. In particular, transactions using the 1,000-zatoshi fee specified in this ZIP will be treated as having no "paid actions", and therefore will be deprioritized by the RECOMMENDED block template construction algorithm in ZIP 317. If they have more than 50 logical actions, they will never be included by that algorithm, and so will not appear in block templates created by zcashd or zebrad with the default parameters. They will also incur the low fee penalty specified in ZIP 401 [10], which will make them more likely to be evicted from the mempool without being mined.
Wallets SHOULD move to using ZIP 317 fees with all due haste.
The conventional transaction fee presently is 0.0001 ZEC or 10,000 zatoshis. At a ZEC market price of USD 100, for example, a user can send 10,000 transactions for 1 ZEC. This works out to 1 U.S. cent per transaction and it rises with any increase in the price of ZEC.
With increase in light wallet adoptions on mobile clients, many users will be new to the Zcash eco-system. And the fact that the transaction fees are paid by the sender (not the receiver) is new information to users who might use Zcash for e-commerce and app interactions that might result in several transactions each day.
Privacy must not cost a premium. The cost of 10 shielded transactions buys 1GB of mobile data in India today.
Zcash users must be able to do more with their ZEC balance than worry about paying the premium for shielded transactions.
With reduced fees, it will be cheaper to transact on the Zcash network, while also inviting novel use cases for privacy-preserving applications that would benefit from the privacy, security, and programmable money aspects of the Zcash chain.
The harmonization of fees between different kinds of transaction can be expected to improve usability, consistency, and predictability.
The change to the conventional transaction fees should be undertaken soon as it gets difficult to gain consensus with the growth in the network of wallets, exchanges, miners and third parties involved.
The following parties need to be part of the consensus:
- Support from mining groups is required to include the lowered conventional fee transactions in the next block.
- Wallet developers need to provide commitment to update the software to use the new fee.
- Zcash documentation and community outreach must be undertaken to make the change known.
Unique 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. Hence this change should be accepted by a majority of shielded transaction software providers before deploying the change.
Varying/unique fees are bad for privacy. For the short term before blocks get full, it is fine for everyone to use a constant fee, as long as it is enough to compensate miners for including the transaction. [2]
Long term, the issue of fees needs to be re-visited in separate future proposals as the blocks start getting consistently full. New ZIPs with flexible fees, such as [3], along with scaling solutions, will need to be evaluated and applied.
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 block chain even if blocks are completely full. However, users sending legitimate transactions may not have their transactions confirmed in a timely manner.
Variable fees could mitigate this kind of denial of service: if there are more transactions available than can fit into a single block, then a miner will typically choose the transactions that pay the highest fees. If legitimate wallets were to increase their fees during this condition, the attacker would also increase the fees of their transactions. It is sometimes argued that this would impose a cost to the attacker that would limit the time window for which they can continue the attack. However, there is little evidence that the actual costs involved would be a sufficient disincentive.
This proposal does not alter how fees are paid from transactions to miners. However, it does establish a fixed flat fee that wallets are expected to use. Therefore during a transaction rate denial-of-service attack, legitimate fees from those wallets will not rise, so an attacker can extend an attack for a longer window for the same cost.
This ZIP does not address this concern. A future ZIP should address this issue. Wallet developers and operators should monitor the Zcash network for rapid growth in transaction rates.
Wallets implementing this specification will use a default fee of 0.00001 ZEC (1000 zatoshis) from block 1,080,000, for all transactions.
zcashd, and potentially other node implementations, implements 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, unless there are other reasons not to do so for robustness or denial-of-service mitigation.
In zcashd 4.2.0, this change is implemented by [8].
zcashd limits the size of the mempool as described in [10]. This specifies a low_fee_penalty that is added to the "eviction weight" if the transaction pays a fee less than (in the original ZIP) 10,000 zatoshis. This threshold is modified to match the new conventional fee in zcashd 4.2.0.
The developers of the following wallets intend to implement the reduced fees:
- Zbay;
- Zecwallet Suite (Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode);
- Nighthawk Wallet for Android & iOS;
- zcashd built-in wallet [6].
In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using z_* RPC APIs. It is planned to extend this to all transactions in a future version [7].
Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira-Emma Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.
| [1] | Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" |
| [2] | Conventional Shielded Fees |
| [3] | Ian Miers. Mechanism for fee suggester/oracle |
| [4] | Zooko Wilcox. Tweet on reducing tx fees |
| [5] | Zooko Wilcox. Tweet on sharing tx fee with wallet developer |
| [6] | Reduce default fee to 1000 zatoshis |
| [7] | (1, 2) Ecosystem-wide standard transaction fee |
| [8] | zcashd commit e6a44ff: Always allow transactions paying at least DEFAULT_FEE to be relayed |
| [9] | ZIP 317: Proportional Transfer Fee Mechanism |
| [10] | (1, 2) ZIP 401: Addressing Mempool Denial-of-Service |