mirror of https://github.com/zcash/zips.git
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
79afded365
commit
755d79f4f2
|
@ -70,7 +70,7 @@ expected to improve usability, consistency, and predictability.
|
||||||
Requirements for consensus
|
Requirements for consensus
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
The change to the conventional transaction fees must be undertaken sooner
|
The change to the conventional transaction fees should be undertaken soon
|
||||||
as it gets difficult to gain consensus with the growth in the network
|
as it gets difficult to gain consensus with the growth in the network
|
||||||
of wallets, exchanges, miners and third parties involved.
|
of wallets, exchanges, miners and third parties involved.
|
||||||
|
|
||||||
|
@ -82,57 +82,67 @@ The following parties need to be part of the consensus:
|
||||||
|
|
||||||
|
|
||||||
Security and privacy considerations
|
Security and privacy considerations
|
||||||
-----------
|
-----------------------------------
|
||||||
|
|
||||||
Unique transaction fees may reveal specific users or wallets or wallet versions which reduces privacy for those specific users and the rest of the network.
|
Unique transaction fees may reveal specific users or wallets or wallet versions,
|
||||||
hence this change must be accepted by majority, if not all popular
|
which would reduce privacy for those specific users and the rest of the network.
|
||||||
shielded transaction software providers before announcing the change.
|
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,
|
Varying/unique fees are bad for privacy. For the short term before blocks get full,
|
||||||
it’s fine for everyone to use a constant fee, as long as that is enough to compensate miners for including the transaction. [#nathan-1]_
|
it is fine for everyone to use a constant fee, as long as it is enough to compensate
|
||||||
|
miners for including the transaction. [#nathan-1]_
|
||||||
|
|
||||||
Long term, the issue of fees needs to be re-visited in separate future proposals as the blocks start getting consistently full.
|
Long term, the issue of fees needs to be re-visited in separate future proposals as the
|
||||||
New ZIPs with flexible fees, such as [#ian-1]_, along with scaling solutions need to be evaluated and applied.
|
blocks start getting consistently full. New ZIPs with flexible fees, such as [#ian-1]_,
|
||||||
|
along with scaling solutions need to be evaluated and applied.
|
||||||
|
|
||||||
Denial Of Service Vulnerability
|
Denial Of Service Vulnerability
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
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.
|
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 variable transaction fees. The block size limit ensures that full nodes and miners can sync blocks even if they are completely full. However it does not protect users sending legitimate transactions to have their transactions confirmed in a timely manner.
|
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 can mitigate this kind of denial of service because in there are more transactions available than can fit into a single block, a miner is assumed to choose the transactions that pay the highest fees. If legitimate wallets increase their fees during this condition, the attacker must also increase the fees of their transactions. This imposes a growing and ongoing cost to the attacker which limits the time window they can continue the attack.
|
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 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 require wallets to use a fixed flat fee. Therefore during a transaction rate DoS attack, legitimate fees may not rise, so an attacker can extend an attacker for a longer window for the same cost.
|
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 for shielded wallets.
|
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.
|
||||||
|
|
||||||
|
|
||||||
Activation
|
Activation
|
||||||
============
|
==========
|
||||||
|
|
||||||
* The new default fee of 0.00001 or 1000 zats must start activation at block 1,080,000
|
Wallets implementing this specification will use a default fee of 0.00001 ZEC
|
||||||
* With a grace period of ~4 weeks (block 1,120,000) to upgrade to the reduced default transaction fee for zcashd and core clients used by exchanges & service providers.
|
(1000 zatoshis) from block 1,080,000.
|
||||||
|
|
||||||
|
|
||||||
Support
|
Support
|
||||||
============
|
=======
|
||||||
|
|
||||||
Zbay, Zecwallet Suite(Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode) and Nighthawk Wallet Android & iOS have agreed to implement the reduced fees.
|
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.
|
||||||
|
|
||||||
|
|
||||||
UX Guidance
|
|
||||||
============
|
|
||||||
|
|
||||||
Wallets must prevent users from altering the fee for shielded transactions.
|
|
||||||
Additionally, all wallet developers and operators should monitor the Zcash network for rapid growth in transaction rates. As we tend toward fuller blocks, we should proactively address the issue of growing mempool in a separate follow up ZIP.
|
|
||||||
|
|
||||||
|
|
||||||
ZIP Owners
|
|
||||||
-----------
|
|
||||||
|
|
||||||
The current ZIP Owner is Aditya Bharadwaj, representing the Nighthawk Wallet.
|
|
||||||
Additional Owners will be selected by consensus among the current Owners.
|
|
||||||
Acknowledgements
|
Acknowledgements
|
||||||
================
|
================
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue