This thread will be used to discuss the ZIP to reduce default transaction fee from 0.0001 to 0.00001 ZEC for shielded transactions.
Paging @holmesworcester @adityapk00 @daira
Looking forward for your contribution.
Please add more related parties to this thread!
Thank You!
BTW, hereâs a nicely rendered version (1) of the submitted draft. This may be nicer for many readers. (This comes with every github pull request, but if youâre not used to github itâs difficult to find.)
Edit:
(1) Whoops, my original link was to a specific revision so it didnât show new edits. I edited in a link that renders whatever is available on nighthawk:master branch, but eventually that might point to something else. Oh well.
Thanks for submitting this! I look forward to seeing what users, protocol/node devs, and wallet devs all think of this proposal.
How do we protect against an attacker who sends a larger number of shielded TXs and floods a block?
How, once we hit block capacity, do we allow transaction prioritization?
On the flip side, given the low block utilization, why not allow free shielded TXs too?
How about we solve these problems by having two default fees, a fast lane and a slow lane? The fast lane could be 2x this new default fee. We can decide to add more lanes as necessary.
Every shielded transaction that pays the reduced default fee of 0.00001 must be considered as a valid z2z transaction and included in the Zcash chain. Maybe we could agree on setting the minimum as a requirement for a shielded transaction, although it might make every wallet holding less than 1000 zats un-useable. As for an ongoing attack, Zcash has large enough blocks of 2MB mined every 1.25mins which will help in clearing the mempool.
Hitting block capacity is a milestone way further out, first we need to start getting near to the block capacity consistently over a period of weeks if not months. Then the community can evaluate the different proposals of scaling via block size increase or side channels or any new invention to compress more txns. per block. In my opinion, transaction prioritization must only happen based on the time of the transaction, and not by creating a fee market or adding Replace-By-Fee. These discussions may be out of scope for this ZIP as the motivation is for allowing free-er use of shielded transactions, to not worry about expending oneâs balance on fees alone.
In my opinion, transactions on a decentralized network must include fees for compensating the miners for the proof of work done. In the long run, the increase in use of the network must result in increased transaction count, thereby increasing total fees collected per block, thus giving way to incentivize the miners to continue securing the network as the block reward halves every 4 years.
How about a higher min fee on even block numbers ?
Zcash chain is no-where near full blocks today. I donât think there is a need to complicate the transaction flow by introducing preferential treatment to certain transactions. Furthermore, having different transaction fees can cause linkability issues within shielded transactions which is not recommended.
Differential fees based on blocks that satisfy particular symmetry relations could add new factors to the game theory aspects of transaction propagation or even intentional delays by exchanges or smart contracts that rely on oracles to execute transactions.
Sure. So i get a bunch of zcash, put it on the chain, and then it costs me almost nothing to flood the blocks with legitimate transactions from me to myself. All i am out is is about 1000 zats X 2 MB/1kb per block. A zat is 0.00000001 ZEC. Zec is 75/USD right now. So thats 0.00075 per tx . So it would cost me $1.5 per block our about 75 dollars an hour to DoS Zec.
This is generally the argument for a fee market right? The fee we have definitely doesnât meaningfully contribute to mining.
To be clear, I agree with you, fees should be lower currently. But the safest and easiest way to do that is to just have a fee market. Since most blocks arenât full, fees go to zero. And we get DoS safety and future proof for increased scale.
And before anyone comes in and says fees are a privacy leak: not really. We can have it set based on past blocks. If everyone uses that, thereâs no privacy leak. Even without that, itâs not that bad.
Moreover, 1) we donât have network privacy and 2) the light-wallet exposes witch TX is yours to the server by automatically fetching the memo.
We clearly are willing to make far more questionable privacy choices.
Daily payout to miners:
-Block rewards: 7,200 ZEC
-Transaction fees: <1 ZEC
Out of scope of the ZIP, but IMO A fee market breaks the user experience of Zcash as a currency.
Crystal/Chainanalysis are on the hunt for every transaction linkability they can find, so I believe the default set fee helps.
Network privacy is in the userâs hands via VPN, Tor, Nym, and other options.
Light wallet server can be run by a user if they donât trust the operators of specific light wallet service providers.
There is always a choice.
No, the idea is that when the adoption hits early majority to late majority, the fees from transactions should exceed the mining rewards to incentivize the miners to provide security for the chain. This is assuming Zcash plans to scale up to demand unlike BTC.
If every client estimates fees based on past blocks, they will all choose the same fee. No privacy problem.
Users can choose not to. Thereâs always a choice as you point out.
I agree its a UX issue for unpredictable fees, so ideally weâd figure out a work around.
However:
the fee you prosed makes its really cheap to DoS the network and gives no adaptive countermeasure (unlike a fee market). Thats a worse UX problem if it happens.
If we are going to have fees and we all seem to agree we need them, we need some logic by which the price is set.
The problem is currently we donât actually have any logic for how we set the current fee.
And no matter how much capacity Zcash adds, it will be readily possible for an attacker to stuff blocks with a massive number of transactions. Their only computational cost is that of proving, which is low.
The slim hope is if we added an adjustable proof of work per transaction that went up as blocks got fuller. iâve proposed this a few time, but it never seems to go anywhere.
âEvery clientâ does not have real time access to the past blocks, e.g. compact blocks, light clients, smart contracts working asynchronoulsy via oracles. What are past block fees even based on? And what happens when the clients estimate the past block fees differently(txn. linkability again)?
This solution gives rise to complexity that might be addressed in another ZIP.
The current ZIP to reduce fees is to simply reduce the default shielded transaction fees from 0.0001 to 0.00001, @daira did mention to include defining the fee for transparent transactions in this ZIP, waiting for more info on that.
How many times has Zcash network been under DoS? I see this as a non-issue. And again, the Zcashâs network capacity will clear the mempool if we ever go through DoS. This change might even help accelerate research & implementation of FROST signatures.
The fee I have proposed is still 5x fees of BCH which uses 1 sat/byte resulting in 195 sats fee for this transaction.
And Zbay is currently using 250 zats per transaction (I may be wrong on this).
If we donât come to an agreement on reducing the default shielded fees, I expect to see 4-5 different transaction fees set for shielded transactions by different apps/clients.
I am not sure if we need to add logic, as setting an inelastic fee has worked quite well for Shielded Zcash transactions till now.
Every transaction that pays the default fee must be considered a valid transaction.
Is there more info on this? A thread or a ZIP?
AFAIK, a âwoodchipperâ style DoS is technically still an issue, and creating a extremely low fee could make it even cheaper to perform:
Sorry, by logic I mean human logic. I.e we never actually thought through how to pick a fee weâd hardcode in the software. And this leads to the weird argument you and I are having where Iâm asserting two intentionally contradictory points 1) fee might as well be zero 2) too low fees lead to DoS.
Because we have no actual framework for evaluating it.
You can trust a light wallet server for estimating fees based on past blocks. Yes if it was actively malicious it could manipulate that estimate. But we already make worse trust assumptions on light wallet servers. And we can remove that trust later by putting the average fee paid per tx for a block into the block header.
Finally, if youâre estimating fees off of a deterministic function of the last n blocks before the anchor you are spending from. there is no risk of clients calculating different fees. Consensus ensures they see the same data modulo forks. And forks already screw you on privacy since the merkle tree root in your tx leaks which fork you are on.
Zero fees is out of the question as it breaks the incentive model for the miners to secure the network following multiple block halvings. If the fees are removed it will be almost impossible to reverse it to add transaction fees back to Zcash when the miners need to be incentivized for providing security to the network.
âLow fees lead to DoSâ is an argument that keeps being brought up as something to fear(without recourse) while totally overlooking and ignoring the benefits of low fees, more accessibility and affordability that it enables; which is the point of this ZIP.
The fix for massive transactions happening on Zcash is to process those transactions that meet the default fee criteria and get them included on to blocks.
The Zcash chain is the framework to evaluate the transactions, the traffic & costs to transact on it vs alternatives. 10,000 zats is too high today and this ZIP plans to gain consensus to reduce it to 1,000.
If you have alternative implementations that can help reduce the fees 10x, please propose it in a ZIP.
This entire approach will result in lock-in engagement of client software with light wallet infra it connects to which makes the transaction flow complicated and worse overall. I would invite other users to provide feedback on your approach. Or this idea of yours is a genius approach for a new blockchain project.
Otherwise, Zcash network being left as a Shielded Highway with standard protocol rules and consensus amongst its users is better, keep things simple. Traffic Jams/Scaling issues are no where a priority today, when we get to 80%+ full blocks we will revisit scaling, Zcash will scale with user growth. Unless there is anyone who believes there is a market for âPrivate Digital Gold 3.0â and wants to blindly follow the steps of BTCâs 1MB forever approach.
If the argument is we should make fees as low as possible BUT it canât be zero because then we can never have fees, ok, I can see that. Then shouldnât we make it one zat?
I realize Iâve been asking all these questions of you and thats actually a bit unfair. The bone Iâm picking is with zecâs current fee structure. Which isnât your fault. Youâre just trying to make ZEC more usable. Which is a really good thing.
The trouble is changing the fee raises all of those questions we should have answered in the first place.
If fees are supposed to pay for mining after the block reward gets too small, then they clearly need to be much higher than they are now. Right now we have fee that basically serves a ceremonial role and might not actually do anything. (it might protect against DoS attacks. $7500 dollars is a lot for someone to troll zcash. $75 is no). So if it truely does nothing, make it 1 zat.
I donât see how.
To be clear: iâm suggesting this happens automatically, not users see fees. Wallets automatically compute the fee they pay based on the average fees in the past few blocks. Normal nodes calculate this themselves. Light clientâs donât see the entire chain, they rely on a server to do some of that work for them like computing compact blocks. So now the light client does this work too. Every light wallet server would do the same computation and give you the same information just like they all give you the same compact blocks. You could move from one server to another. Thereâs no lock in.