ZIP317 Grace Window Upper Bound is Too Expensive

[zancas]

https://github.com/zcash/zips/blob/main/zip-0317.rst#grace-actions

Prior to ZIP317 fees, it was possible to pay a single tx-fee for ~2000 actions. As constructed this proposal (while also varying other parameters) would change that number to 2. The bounds on this parameter were selected based on two criteria:

1. Allow for a feature that the community universally wants, "free change"
2. "maximize the per-logical-action cost of denial-of-service attacks"

The second consideration is given too much weight in this process. If the grace-window has an upper-bound larger than 2, that allows for wallet developers to implement splitting/sweeping policies that can significantly enhance User Experiences.

[daira]

I think we should implement the current specification and see how well it turns out.

[zancas]

I'm motivated by User experience.

Users should never be blocked on spending because their only note is a change-note that's not sufficiently confirmed.

One of many use-cases for multi-output (greater than 2) transactions is note preparation, that provides a wallet with more spendable funds.

In short, a grace window of 2 will constrain how Zingo can innovate with no proven benefit.

On the other hand, a grace window of 20, will still cause a 1000x (this factor includes the minimum fee bump) increase in cost for maximum output (SandBlast) transactions, while allowing ample space for innovation.

[daira]

If the grace window were 20 then we would probably have to decrease the marginal cost of a logical action (unless you're arguing that all transactions that would be under 20 logical actions should be more expensive?), and that would make the sandblasting transactions correspondingly cheaper. The latter may already not be expensive enough under the current ZIP 317 proposal to discourage the DoS; we don't know yet, and won't until we implement it.

[zancas]

I agree that how much this mechanism will dissuade SandBlasting is unknown.

It's also unknown how much it will cost other activities. Since we're operating without much data maybe the best approach is to make tuning this parameter as easy as possible?

The SandBlasting is not the only variable. That seems clear to me.

[daira]

ZIP 317 has been deployed without this change, which will not be implemented (with the rationale I gave above). The deployed algorithm appears to be having some success at limiting the sandblasting.