This is great. Thanks @aiyadt for doing the hard work of starting the ZIP and shepherding the conversation forward!
There are a few considerations that I haven’t seen mentioned:
checkpoints
exchanges
hardware wallets
Today, most light clients start from a checkpoint (birthday) and may not have all chain state available. Any solution that is a function of chain state must account for use-cases, such as hardware wallets, where that chain state is not available. Also, shielded withdrawals are now supported on Gemini. We just did a brown bag yesterday with their engineering team and the topic of fees came up. If we change the fee to some kind of complex, dynamic, future-proof solution, then it will have a non-trivial impact on what they’re building. We should definitely factor in their perspective before settling on anything.
This ZIP, as I understood it, is scoped to establishing a new “conventional” fee, rather than propose changes to the protocol or wallet fee mechanisms.
This is a key distinction to make. It sounds like there should be another ZIP, with a longer horizon, that moves us in the direction of something like EIP-1559 with innovative economics. Meanwhile, this ZIP can help us iterate toward a near term solution that could possibly even coincide with the Canopy activation.
I think Zbay, Zecwallet, and Nighthawk have all informally agreed to adopt the lower fee as the default, and we could get formal commitments here.
Zbay can formally commit right now to using this fee and preventing users from altering the default fee on shielded transactions once the ZIP is approved.
Thanks for the commitment! And thanks to @nathan-at-least & @gmale to add clarity and definitions. I will update the ZIP with your inputs and ask for a review again.
Thanks to @secparam to really dive in to this discussion as the transaction fee is definitely intertwined with the overall network functionality at the larger scale. And since it has been pointed out that this is a conventional fee change, in line with maintaining user privacy, this change will open up novel applications while adding ease of use for z2z transactions.
I’ve added the UX Guidance section with your input Sir!
This is correct, and this new “conventional” fee will require the updating of fee constants used in wallet/transaction building code across Zcash software.
We probably need to start getting clarity on this. As @adityapk00 has shown, this change doesn’t necessarily require changes in zcashd. Getting this done and implemented in time for Canopy feels doable.
At the same time, we are kind of charting new territory here and many of us are new to writing ZIPs. So we should make efforts to ensure that everyone is on the same page for how this ZIP process will unfold. Is it possible to be “results oriented” and agile here? Can we make incremental progress and modify the ZIP and code, as needed, whenever we need to make adjustments, later?
Is everyone okay with limiting the scope of this ZIP to just reducing the “Conventional fee”
while saving a larger more comprehensive fee change for another ZIP along the lines of EIP-1559?
If so, can this change be made primarily in one place so that it is less code to manage in fewer locations AND if it needs to be tweaked in the future, everyone gets it “for free?”
Reducing the friction of future changes seems to be an effective way to “favor results over bikesheds” in the present.
I represent horizontal systems and last few years we have been building mobile wallets for various blockchain protocols i.e. SPV client for Bitcoin.
Now, here is our take on network fees.
At this point in time the two blockchains where setting the right fee is problematic are Ethereum and Bitcoin. Each has its own native fee estimate mechanisms and both often fail when network activity changes. In other words, the client developers are not able to fully rely on native fee estimate mechanisms provided by the network nodes.
On a client side we typically show user an estimate (1-2 hours) for a selected fee range (low, normal, high). It’s not uncommon for the transaction to remain pending for a lot more hours then estimates or get processed in a few minutes while user expected it to take hours. So, there is a window for confusion for the sender of the funds. If the transaction remains pending significantly longer than it often results in user being worried as few currently understand what these transaction fees are. So, long story short, existing fee estimate mechanisms for busy blockchains work partially and we are yet to see something that works well for all cases.
I think fixing the fee while blocks are not getting full is a working idea. We already do this for blockchains like DASH, Litecoin and Bitcoin Cash. The 0.0001 comes down to less than a cent which is comparable to those of BCH.
That said, someone mentioned that 0.0001 can be abused as filling the entire block with to-self transactions would be still fairly cheap…
It goes without saying that at some point there should be some kind of fee estimate mechanism which depends on the current state of the mempool as it can be locally accessed by each node and indicates the current activity on the network.
ZED is a better unit than ZEC because ZEC is good for large transactions and bad for small transactions, while ZED is good for small transactions and okay for large transactions.
Coffee: 0.0001 ZEC (bad) or 100 ZEDs (good)
Remittance: 1 ZEC (good) or 1 million ZEDs (okay)
Basically, we just need to avoid having prices more than 1 or 2 places to the right of the decimal. People are fine with a thousand or a million. They are not fine with a thousandth or a millionth.
A new Zecwallet release is out (v1.3.3 lite client and v0.9.20 full node) that incorporates this ZIP. Default fees will switch over to 1000 zats after canopy + grace period (Block 1_080_000).
This really helps when pricing in Zcash, ZEDs for 1000th unit instead of worrying about decimals. And ZEC for dealing with base 21 million layer.
This change will need user testing as @daira suggested in the GitHub thread. And light clients might be the ones to help test it out. A community poll might help to check if Zcash users are open to adopt the unit based terminology. Can someone volunteer to create one?
Note: Keeping the terminology simple(& to the brand) should be the goal, as Bitcoin failed the millibit experiment Millibit - Bitcoin Wiki
Wasn’t a π Zec supposed to be like 100 zat or did we ever decide? I cant remember (though it was from a show I never watched, something carbon I think)
I just posted a github review of the current ZIP draft. Here are high level bits for discussion. Edit: It was super long, so I split two different sections into different replies to improve threading.
What about transparent transactions?
This is one outstanding major gap from my review reading.
The motivation for making privacy cheap to enable new use cases is a great one, but it doesn’t seem to apply to fully t->t transactions. Should this ZIP say that fees for t->t transactions can vary? What about the trickier cases of any transaction with both shielded and transparent components?
Relevant considerations include:
Usability - it seems nice to me if all txns have a single flat fee, because it’s easy to understand and plan around UNTIL blocks are full.
Ecosystem adoption - there are many many more transparent Zcash wallets and many of them don’t necessarily follow Zcash too closely because they just port a Bitcoin thing and move onto the next coin. So I’m not sure what fraction of transparent wallets would follow the ZIP.
Transaction-rate Denial of Service - if all wallets always keep a flat fee, this makes TR-DOS vulnerability worse. (Again, I personally advocate for addressing this in one or more separate follow up ZIPs.) But if some wallets vary fees, especially transparent wallets, then during a TR-DOS event, users may begin unshielding their ZEC in order to make transactions go through, which is worse for privacy.
My personal position: The ZIP should apply to any transaction with any shielded component. This strikes the following balance:
Usability - Users are already hopefully aware of the Z / T distinction, so while “all transactions use flat fee F” is very nice, I think “all transactions involving a shielded address use flat fee F” is still pretty good.
Ecosystem - Any wallet that can generate shielded components is much more likely to be proactively engaged with Zcash development so the adoption of
the ZIP is much more likely to be widespread.
TR-DOS - Not well addressed. Users who use “legacy Bitcoin-like” t-addr wallets will fare better in a TR-DOS. Since most transactions are t->t currently, there’s a nice systemic defense here because the fees should raise during an attack and limit the attack window, even though the downside is that
any shielded transaction may not confirm during the window.
There is another issue about deployment timelines: I’ve already seen one case within ECC where people weren’t aware of this new fee change which disrupted a user education project. This is very closely related to the “Network Upgrade Pipeline”, which we’ve been striving to improve in the Arborist calls.
My personal position: We should proceed with the current timeline and momentum for this ZIP but also figure out how to roll out future wallet / ecosystem changes like this in a way that helps keep the ecosystem in sync.
My personal position: It seems like a good step would be for (zcash-specialized) wallet developers to attend Arborist calls, because it’s best for those conversations to cover the full “zcash-focused / shielded” product stack rather than “just consensus protocol” because I think this is a good case study where we need collaboration across wallets and ecosystem on privacy, usability, and adoption which sometimes requires consensus changes but sometimes does not.
there should fee estimate mechanism which depends on the current state of the mempool
While I agree with the spirit, I would argue that fee estimate mechanism would be too complex for shielded transactions. Such fee estimate mechanism must be implemented with high accuracy (considering network latency, peer availability, on-chain activity, etc.) and agreed by all client teams, for all shielded transactions to be unidentifiable from one another.
As far as on-chain privacy is concerned, setting a conventional fee that is agreed by wallet implementations, like now, is ideal for the foreseeable future. Also, I don’t think we need to worry about network congestion considering improvements made (or will be made) in the protocol privacy, scalability and usability.
I don’t have as much of a horse in the race when it comes to unshielded transactions, since Zbay deals mostly in z2z transactions, but I think the same privacy issue does apply, since if any user’s fee-selection pattern differs from any other user with t-transactions, they can be fingerprinted.
An attacker might be able to see two separate t-address transactions on-chain without knowing they correspond to the same user. But if the fee choice is very unique, the attacker would be able to link the two transactions. Privacy might not be as critical for t2t users, but that doesn’t mean it doesn’t matter. Some users might have to use t-addresses in some situations (like dealing with an exchange that’s behind on their zcash support, e.g.!) and since they’re using Zcash they still probably want as much privacy as we can reasonably provide them.
So perhaps the recommended mode should be to use the new default fee for t transactions too, and if in the future blocks become congested, we use the fee selection algorithm for both transparent and shielded transactions.
It’s possible some wallets are gonna keep doing their own thing, but if they’re already doing their own thing then their users are somewhat likely to be unprotected from this attack already, so this wouldn’t worsen their users’ privacy.
Again, I don’t care as much about this question, but the above approach seems like the right thing to do.
A related question would be, if we don’t make the fee the same for unshielded transactions, what is the most privacy-friendly fee for these transactions? What should wallets do?
Good point. And it affects even those who try to use shielded transaction, and even maintain their “daily use” wallet as a z-address, but are occasionally forced to transact in t-addresses due to constraints of counterparties or hardware wallets. Done right, this can be done in a way that preserves privacy pretty well. However, it would be foiled if unusual transaction fees link the user’s excursions outside the shielded pool.
Agree, the Timeline to lower the shielded transaction fees sneaked up too quick.
Would an update to the Activation as per the follow work?
The recommended fee of 0.00001 or 1000 zats must start activation at block 1,080,000
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.
