ZIP317 Grace Window Upper Bound is Too Expensive about zips HOT 5 CLOSED

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

from zips.

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.

from zips.

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.

from zips.

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.

from zips.

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.

from zips.