I would really like this EIP to be implemented.
I’ve started gathering data on gas fees - I don’t know if somebody has similar charts already
What could ETH user with some basic python / data analysis skills could do to push it further?
Is it possible to donate money for people working on this?
What is the time frame for this?
My main problem for this EIP is that there is no clear champion taking leadership around this change.
The only one to be hurt by the current situation are end users.
Further preliminary data: minimum gas fee “safe low” is gravitating towards multiplies of 5:
The histogram looks gaussian around 10 gwei but also like exponential decay at around 1+
It suggest that there is very large demand for getting sub 1 gwei transactions cleared - but question is what’s the limit of ETH network in this regard?
What’s the optimal gas fee that’s a compromise between UX and maximising the security of the network and network value?
@guthlStarkware we’re targeting Berlin currently.
@kwikiel thanks for these analyses. I’ve seen this graph which may be relevant https://gitcoin.co/gas/history
how are you defining safe low/standard/fast here?
with regards to donating money, we are coordinating partners and budgets at the moment.
we should have updates shortly.
Why would the miners ever raise baseFee?
Great! One solid way to do this would be to set TARGET_GASUSED as a hardcoded value, especially for Ethereum Classic.
The full-nodes are the ones that have no input, output, or incentive no matter what you do to this market (it is between miners and users alone). Full-nodes are essentially volunteers so hard coding the TARGET_GASUSED low enough, such that anyone interested in running a full-node can do so without significant cost. Of course “significant” is a matter of debate but having users or miners affect this value is worse than developers, as their incentives are known to be different than full-nodes, however there is no way to get a sybil-proof opinion from them so as a consolation the devs (having less of a conflict-of-interest) decide. Ethereum of course has different security tradeoffs so I would love to know if you have a different variation. link?
Making things better for full nodes should be addressed other ways. the purpose of the gas price is not to make things easier on full node operators, a different mechanism should be used.
look for champions soon (hopefully)
For the existing proof-of-work system it may actually make more sense, instead of just burning everything collected in BASEFEE, to put some or all of it in a fee pool to be distributed equally among the miners of the following x blocks. That way you preserve the current incentive structure for miners as a collective where they want total fees collected to be high, and you should be able to also keep the current system where miner voting controls the network’s capacity.
If you burn all the base fees, the next step seems to be to say, “OK, we can’t trust miners to control this so we need to replace the miner voting mechanism”, and you end up potentially shaving a lot of yaks unrelated to the original fee market improvements.
I should probably post this in here, shouldn’t I 
Cross-posted from here:
If we imagine a large backlog of transactions whose submitters have widely varying preferences of the highest price they would pay, then I think it should be simple to prove that:
Under 1779:
BASEFEE increases to a level that excludes other transactions, making the tip a sort of single-price auction within each block that reproduces all the problems of the current market but with the additional complexity of this one.BASEFEE is going to lower again, the lower-priced transactions remaining will need to wait additional blocks for the price to fall to be eligible for inclusion.Under the Escalator algorithm:
cap and max_duration).I would like to see time-to-return-to-normal-fee mapped against volume-of-tratsient-congestion-spike to get a better idea of whether this is something I would care about.
I suppose it depends on how long the congestion lasts (how long does the system have to increase the fee rate)… does that mean we need a 3 dimensional graph?
A huge spike of transactions of size k*L (assuming gaslimit L) in non-EIP-1559 land would last k blocks. In EIP 1559 land, there would be a “full blocks and increasing fee” phase that lasts k/2 blocks (assuming max_gas/target_gas = 2) and then a “decreasing fee” phase that lasts another k/2 blocks because the decrease would be the same as the increase. The difference though is that in EIP 1559 land, during the decreasing fee phase transactions willing to pay a temporarily increased fee would be able to immediately get in, whereas currently they would still have to compete with the transaction spike. If max_gas/target_gas > 2, then things are even more favorable for the EIP 1559 case, though that could lead to unacceptably high burst load for clients in the network.
Just looking back over this thread I noticed that quite an important aspect hasn’t really been discussed, namely: Does paying fees to miners (beyond the minimal amount they’d get in tips) help secure the network?
I guess this isn’t attracting a lot of attention right now because fees are pretty low compared to the block reward (something like 3% on average) so any contribution they’re making is fairly insignificant and hardly worth wasting pixels over.
However, already there are some times when fees become significant - the recent case was when ETH crashed and there was a spike in defi activity. It strikes me that times like this are currently the security worst-case for Ethereum: Security spend is abruptly dropping (because ETH crashed) but at the same time the value transacted on-chain is very high. High value transacted on-chain makes attacks - whether rolling back the chain to change transaction order or censoring transactions - more profitable, so we need more security spend to disincentivize them. If there was nothing of value being transacted then there would be nothing to gain by messing with the transaction history, but if there’s a lot of value being transacted then there’s a lot of money to be made.
If this is right then fees paid to miners act as a kind of automatic stabilizer where the security requirement is (at least somewhat) correlated with value transacted, and value transacted is (at least somewhat) correlated with fees paid.
You can then look at this from either end: Either we hold our desired level of security constant and think about the block reward we’d need to get that amount of security, or we look at the amount we’re spending and try to work out how much security we’re getting. If we hold the block reward constant, we’re looking at a loss of least the 3% or so that is currently going to miners, but also some amount potentially much greater than 3% in the low-ETH-value high-transacted-value worst-case. Or if we hold the desired security level constant, we need to raise the block reward not only by the 3% or so that covers the average fees, but also by some additional margin to cover the worst-case. This seems particularly relevant as this EIP is being sold in other venues (not here) as something that will reduce net ETH issuance and thus benefit holders, when in fact it seems to do the opposite.
If we want to keep the proposed fee market mechanism without this effect on network security (or inflation, as you prefer) the alternative would be to put basefees into a fee pool, where they’re spread among all miners mining blocks at about the same time, rather than paying them all to the miner who mines that particular block.
Figured I should post this here: we are having a 1559 implementers’ call this week. https://github.com/ethereum/pm/issues/167
Great to see the fee market instability being addressed. This proposal is strictly better than the current first price fee mechanism being used in Ethereum today.
However, this proposal does not maximize social welfare. Additionally, this proposal is missing formal proofs for the nonmanipulation claims. In practical terms, while we don’t know of a concrete attack on this mechanism right now, such miner manipulation attacks may exist and would be discovered in production.
These issues were brought up and addressed in StableFees, an alternate auction mechanism that maximizes social welfare and has provable non-manipulation guarantees. In a nutshell, StableFees starts with a generalized second price auction and then adds a few rules to provably deter misbehaviors that occur in the decentralized setting that do not occur in traditional auctions.
If you are curious to learn more, a more detailed overview of StableFees is given in this blog post: https://hackingdistributed.com/2019/01/22/doing-fees-right/. For more gory details and proofs, the full paper can be found here: https://arxiv.org/pdf/1901.06830.pdf. Note that StableFees does not rule out colluding behaviors.
Currently, EIP-1559 changes the block sizing strategy from miner-voted to core-dev-asserted. While this change may be reasonable in its own right, I believe it should be discussed on its own merits and included in a separate EIP. For that reason, I have submitted https://github.com/ethereum/EIPs/pull/2635 which removes the core-dev-asserted block sizing and updates EIP-1559 to retain miner-voted block sizing.
If the authors believe that miner-voted block sizing is bad and should be removed, I support submitting an EIP to do that and including arguments as to why it should be done. 
IIUC, the current planned strategy is to enable a slow migration from legacy gas pool to EIP-1559 gas pool to allow dapps time to update to the new model. I think this is a good idea, but we need to consider the fact that during this transition, the max transaction size will be significantly reduced from block-size to about half of block size at the start of the transition. This may cause some contracts that depend on large transactions to break until the migration is far enough along that they can once again issue their large transactions.
As an example, some Augur transactions can get pretty hefty, as well as some 0x transactions (batch fills though, which may be splittable).
At the least, I think this should be mentioned in the backward compatibility section of the EIP.