ZIP: Reduce default Shielded Transaction fee to 1000 zats

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!

7 Likes

BTW, here’s a nicely rendered version 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.)

3 Likes

Thanks for submitting this! I look forward to seeing what users, protocol/node devs, and wallet devs all think of this proposal.

4 Likes

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?

6 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

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.

1 Like

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.

3 Likes

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.

5 Likes

Daily payout to miners:
-Block rewards: 7,200 ZEC
-Transaction fees: <1 ZEC

2 Likes

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.

2 Likes

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:

  1. 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.

  2. 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.

1 Like

“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?

1 Like

AFAIK, a “woodchipper” style DoS is technically still an issue, and creating a extremely low fee could make it even cheaper to perform:


2 Likes

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.

1 Like

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.

1 Like