Protocol Improvement: restrict fees by consensus to follow the current fee schedule.

[shielded-nate]

Currently, I believe we have a relay policy that allocates a portion of blockspace to ZIP-317 fee-compatible txns, with a smaller space for open-ended fees. This is a practical migration strategy to nudge older bitcoin-style wallets towards the prescribed fee regime.

We should consider requiring by consensus that transactions follow a given fee regime. This requires careful consideration of the restriction rules!

However, there are a variety of motivations for doing this:

• compliance: by completely denying non-conformant fees, older wallets are forced to upgrade (if they are responsive to users; if they are not, it's good for users to learn that earlier rather than later!)
• privacy: if fees are more uniform there is less privacy leakage due to wallet or user-specific behavior around fees.
• protocol security/resilience: if we can rely on txns following a prescribed scheme for fees, we can leverage that to reason about network behavior in different scenarios as far as fees are concerned.

Note: I believe it's important that future fee regimes can distinguish between at least one bit (and ideally only a single bit) to distinguish between users who value lower fees with worse throughput/alacrity service-level versus users who prioritize better throughput/alacrity service-level over cost. I believe this bit of information is important for dynamic fee or dynamic block space designs (and should explain more sometime why I believe this).

[zookoatshieldedlabs]

Agree that the consensus rules rejecting non-standard fees would be an improvement in safety, privacy, and UX.

[daira]

The rationale for keeping fees out of consensus has been that we might need to change the policy more quickly than would be easily allowed by a Network Upgrade, for example to respond to a substantial increase in usage or a denial-of-service attack.

The most significant past instance of needing to change fees was to respond to the standblasting DoS attack. Even without any attachment to consensus, the well motivated fee policy change specified in ZIP 317 was resisted for a long time by ECC management at the time (primarily @zookoatshieldedlabs), who essentially vetoed it over the strong, and eventually successful, objections of ECC engineers. Once that fee policy change was enforced, it almost immediately mitigated the attack.

If fees had been tied to consensus then this would have required another network upgrade soon after NU5, which would have caused us significant additional stress and might have even further delayed the successful mitigation of the sandblasting.

Given both governance changes, and the probabilistic enforcement mechanism in ZIP 317's block template construction algorithm which could be easily reused, a future policy change that increases fees could be introduced much more quickly than ZIP 317 was, provided it is not tied to consensus. I believe this is a necessary provision to evolve the network.

To anticipate a possible objection, I do not think that the argument that it should be possible to do Network Upgrades more quickly is persuasive here. The ability to change fee policy should not be coupled to the success of that, and there are some aspects of Network Upgrade scheduling that impose latency that cannot be reduced.

Also, I think that for now, this proposal is trying to solve a non-problem. Well maintained wallets use ZIP 317 fees, and the ZIP 317 fee is successfully enforced by miners as a minimum (both zcashd and zebra now set the unpaid action limit to 0 by default). It is not clear why there is any need to enforce a fee maximum: in practice, the setting weight_ratio_cap = 4 for the block template construction algorithm means that there is no advantage to paying greater than the ZIP 317 fee by more than a factor of 4 (under the assumption that most miners follow that algorithm, which is currently true). The explicit fee field proposed in ZIP 2002 will be sufficient to ensure that wallets do not accidentally overpay fees by miscalculation.

[daira]

@shielded-nate mentioned Bitcoin-style wallets that do not follow ZIP 317:

This is a practical migration strategy to nudge older bitcoin-style wallets towards the prescribed fee regime.

The reason why some Bitcoin-style wallets do not follow ZIP 317 is that they are poorly maintained. They often are unable to properly follow Zcash wallet specifications in general. I believe such wallets are becoming less and less relevant with the increasing usage of Zashi and other shielded wallets. If we cannot successfully engage with the developers of a given wallet to persuade them to follow Zcash specs, we should discourage use of that wallet. There are many disadvantages of using a poorly maintained wallet aside from its fee policy.

[nuttycom]

I have a more philosophical objection to the notion of fees being prescribed by consensus: this couples the miner's choice of network consensus rules that govern when transactions are considered to be valid to them being compelled to take a certain amount of value from each transaction as a fee. From my perspective, this then results in a situation where the protocol is intervening in the market for validation.

In the future, if an EIP-1559 style mechanism is proposed, I will argue that only the "burn amount" be set by consensus, for the same reason. Along the same lines, I think that if ZIP 235 were proposed as a change to consensus, that only the part of the fees directed to the NSM should be set in consensus.