I think this statement mis-frames the inclusion criteria. Here’s a mirror image:
I still fail to see how "just
basefee plus some small
tip" would translate to lower net-wide fee variance (when comparing periods of low/high demand for gas). And, more importantly, that average
basefee+tip would ever be lower than the current average
fee. As @fubuloubu wrote:
(I’ve heard this being mentioned at the rumour mill, that “
EIP-1559 issue 1559 === cheaper transactions”; not in this thread yet.)
The trade-off for the miner is currently between
In the proposed scheme, it would be between
Miners include transactions in blocks based on the marginal profit increase they would get, offset by the chance that the block would become an ommer. Currently, fees rarely make 5% of base block reward. (This was <3% before the most recent issuance reduction; sorry I can’t link a chart: the numbers are from anecdotal personal observation.)
Let’s generously assume that the average fees per block are, in fact, 5% of the base block reward (that is, they are 0.1 ETH and 2.0 ETH, respectively). So, miners have to weigh this 5% extra gain at probability
P against a 12.5% loss (at best! 25% for 2-block-old ommer) at probability
1-P. The profitability condition is:
0.05 * P > 0.125 * (1 - P) P >~ 0.714 0.05 * P > 0.25 * (1 - P) P >~ 0.833 ... F * P > U * (1 - P) # F: extra profit percentage when getting Fees P > U / (F + U) # U: loss percentage due to becoming Uncle
Back to what I started with: I fail to see how lowering user-born fees (and by necessity lowering
F is the
tips part in
basefees+tips, and ostensibly
basefees+tips < fees…) will result in anything but the miners becoming reluctant to include transactions.
It’s reasonable to expect the opposite: average
basefees+tips under this proposal will be higher than average current
(There! It’s out of the way now.)
The scheme further breaks down in times of “congestion”; that being a descriptor for increased average uncle rate: an ever-larger proportion of hashing power contributing to “security of the chain”, but not (i.e.: at the expense of) transaction throughput.
During congestion, when relatively many ommer solutions are available, miners:
- routinely have the option to include ommer references in their blocks - because, hey, they keep popping up!; and
- are increasingly pressed to drop transactions altogether - because “no compute” is much faster to process than the “much compute” blocks from the competition (ones that would do well to get out of the way and become ommers…).
Transactions are now in competition with uncles; in particular, the highly-priced transactions (that tend to catch the eye and prompt “congestion!.. congestion!..”). If they can’t “outbid” the inclusion of an uncle (adjusted for the risk of the block itself becoming an ommer!), then it is not rational for miners to include transactions instead of ommers.
This is not specific to the proposed scheme, but is also the state of affairs currently (and manifested mildly in late 2017 and early 2018, I believe).
As noted in the github issue 1559 summary:
If a transaction sender highly values urgency during conditions of congestion, they are free to instead set a much higher premium and effectively bid in the traditional first-price-auction style.
In other words, during congestion, the proposed scheme devolves (at best!) to the current auction mechanism. All good here, except the “at best” part: see previous section.
Somewhat OT: I am against lowering user-born transaction fees wholesale, until a “state fees” portion is introduced to them.
Any scheme that claims to lower user-born fees needs to consider that state expansion gets this much faster when user-born fees are that much lower. The cost is now born by someone else than the users, but they are not gone.
That said, I do appreciate burning a portion of ether, as a means to balance (counter-act) newly-minted ether.
Finally: having both a
gasprice_tip (per-gas-unit, in shannons) and
cap (per-whole-tx, in ether), where
gasprice_tip * gas_limit <= cap;
basefee <= gasprice_tip * gas_limit;
basefee <= cap.
… will be a nightmare for UX; and will most likely devolve into
basefee <= cap as far as wallet interfaces are concerned, with
gasprice_tip abstracted away as a percentage of