[ZIP TBD] Dynamic marginal fee adjustment based on mining latency

[daira]

@nuttycom wrote:

In other chains, don’t they have some mechanism that uses the amount of time that transactions spend in the mempool as a guide to fee selection? What I’m thinking about is that even though we don’t want users changing fees based on some price oracle, I think there’s less of a problem with a miner choosing a price oracle and using that oracle to make decisions on block inclusion. What if the miner chooses a fee (in fiat) that they would accept based upon some oracle, and then uses a mechanism whereby transactions that pay less than that fee are delayed by a number of blocks proportional to the amount they underpay the fee by? Then, if there’s a way for clients to observe how much transactions are delayed by, they can infer the ZEC amount of fee that they have to pay.

In context, this was a response to the mechanism proposed in #1157, and so I think "marginal fee" was intended where this quote says "fee". (If not, @nuttycom can correct me.)

IMHO there's a mild overspecification in that description: we don't have to specify miner behaviour; we only have to specify wallet behaviour. If a miner's policy is to require at least a given marginal fee (in fiat or otherwise) for all transactions they include, their optimal strategy is then, I believe, to delay transactions by the number of blocks needed to cause conforming wallets to pay that marginal fee. The ZIP should say that. However, miners could have strategies compatible with this mechanism that correspond to other kinds of policy, e.g. depending on how full blocks are or how other miners are behaving, and that doesn't cause a problem I think.

Regardless of miners' policies, they are participating in an ascending-price Dutch auction in which the lowest marginal fee wins. (Dutch auctions are usually described as descending-price with the highest price winning, but this case is just the mirror image of that.) As proven in [Vickrey 1961, section III], a descending-price Dutch auction is strategically equivalent to a first (highest)-price sealed-bid auction. Therefore, an ascending-price Dutch auction is strategically equivalent to a lowest-price sealed-bid auction.

(More precisely, [Vickrey 1961] proves that these auctions lead to the same bidding strategies and outcomes under the Independent Private Values model introduced in that paper. [Milgrom and Weber 1982] extends this result to a more general model, and also points out that the proof "requires that each bidder know the value of the object to [themself]", i.e. in this context: a miner does not gain information about the marginal fee it is prepared to accept during the bidding process.)

[linear]

COR-960

[nuttycom]

There's a slight complication with this mechanism in that it's not quite an auction, because the miners are competing to win blocks, but the fee received does not affect whether or not a miner wins a block.

An auction mechanism can make sense if blocks are full. But what we want is a control algorithm where the target value is user experience; I'm not sure this (or any dynamic fee idea) is actually going to work without a mechanism that provides feedback from user experience. The Zcash chain was basically fine through sandblasting; users were not.

Thought experiment: Mobile wallets can wake up when connected to power and wifi and do about 5 minutes of processing. It would be good to know how many Orchard outputs a mid-range mobile phone is capable of processing in a 5 minute period; we should perhaps restrict block size to make sure that we hit that target. At that point, an auction mechanism can begin to function.

[aphelionz]

If you squint, it looks a little like the mechanism proposed here: https://arxiv.org/pdf/2402.17474 which I referenced more or less in passing on the fees website at the very bottom. Maybe take a look at that paper and see if you can also spot any useful overlap?