This is incorrect. Profit seeking miners not executing a censorship attack against the network should include all transactions where: max_fee > base_fee + minimum_inclusion_fee && inclusion_fee > minimum_inclusion_fee
minimum_inclusion_fee should be set by profit motivated miners to just over opportunity cost of inclusion (expected to be around 1 nanoeth).
This is also incorrect. Marginal cost of inclusion is approximately linear with gas used. In fact, a major aspect of gas pricing is trying to ensure this is true.
I find @editor-Ajian 's blog post does a pretty good job at showing that essentially the same market forces are going to be driving gas prices around equilibrium, it was badly needed given the amount of misinformation there is falsely claiming that this proposal is going to reduce gas prices (Thank you for it!). That said I also think that @barnabe and @MicahZoltu have a point showing that the auction mechanism proposed in this EIP has certain theoretical advantages in its dynamic behavior away from equilibrium.
For instance, I agree with @barnabe that the proposed auction mechanism is likely to reduce the pricing imprecision of the current mechanism, and I agree that the base fee can be made to track some stable and more or less objective market price predictably enough (which is critical to keep users from overpaying under significant block-to-block demand volatility), with the caveat I already hinted at that both of these benefits are to some extent mutually exclusive (best stability requires BASE_FEE_MAX_CHANGE_DENOMINATOR to approach infinity which causes the pricing mechanism to revert back to a first-price auction negating the pricing precision benefit, and vice versa, best pricing precision requires BASE_FEE_MAX_CHANGE_DENOMINATOR to approach zero which can lead to high base fee volatility exposing users to overpaying more than they do today), so the practical realization of this proposal is necessarily going to have to make some sort of compromise between the benefits it promises to deliver, which is why I’ve been such a PITA trying to agree on some precise enough definition of what we mean by “improving usability”, since only that way can we answer the question of whether this proposal is going to be cost-effective to the community by some quantitative metric (even while compared with the simplest alternative imaginable of slightly increasing gas limits which incidentally would have advantages near equilibrium that this proposal lacks).
I think that expressing the intended benefits of this proposal in some objective scale is made all the more urgent due to the intertwining of the intended usability improvements with a monetary policy change. Any monetary policy amounts to a redistribution of value from one sector of the community (e.g. whoever is burning their ETH) to another one (e.g. whoever is holding significant amounts of ETH), so I don’t think that @editor-Ajian 's depiction of the base fee as a tax is particularly far-fetched. I believe that the fact that these two changes are being proposed as a single EIP (IMHO without a technical necessity to do so) has greatly contributed to polarization and hampered consensus so far, because it’s extremely difficult for people to judge a proposal based on its actual merits and risks to the greater community whenever they have something to personally win or lose out of it, even if they’re doing it with their best intentions to contribute something positive to the community.
So I suspect that a roughly orthogonal route to get this proposal to gain more traction would be to separate those two aspects into two different proposals (E.g. by implementing the proposal of rolling-average banking and redistribution of the base fee suggested by Tim Roughgarden, which would incidentally also address the incompatibility between this EIP and a fixed-supply monetary policy). At the very least that would fully dissipate the perception of a conflict of interests behind any argument for or against the fee structure reform being discussed here.
That sounds like your purpose with this proposal is just to optimize the gas cost of a fixed-size 12M gas worth subpopulation of the population I was optimizing for, with the constraint that their transactions be included “quickly and reliably”. (I’m a little surprised to hear that after you’ve told me several times you don’t care about optimizing gas costs… But okay I’m fine with that… )
What should “quickly and reliably” mean? Having more than a certain high probability of being included into the next block? Or something else?
As I see it, there are three salient cases that entirely cover the space of transitions from one basefee to the next:
Current effective demand is higher than target, but lower than block limit.
Current effective demand is higher than target and higher than block limit.
Current effective demand is lower than target.
(maybe Case 4: effective demand is equal to target is simple enough)
In cases 1. and 2., basefee increases. In cases 1. and 3., users can bid the marginal cost (or some upper bound) and receive immediate inclusion. In case 2., users have a temporary incentive to deviate from the marginal cost tip, and possibly to bid against each other.
The cases where basefee is 0 doesn’t seem relevant, but making the distinction between 1. and 2. is important to see the tip dynamics.
There still appears to be a fundamental misunderstanding here, so I’ll try and formalise the argument. I am a miner and it is my turn to mine a block. I have a cost for supplying the block and gas, which we’ll call f(S), where S is the amount of gas supplied in the block. What is that cost? The most important part is the risk of my block becoming an uncle. The larger the block is, the slower the propagation, the higher the risk.
f(0) = b, where b is some constant, meaning that if I mine an empty block (no transactions), I still have to send around a few bytes, so the risk of being uncled is non-zero. If there are increasing marginal costs, say, linear in the gas already supplied, then f(S) = b + a * S2, where a is some coefficient.
Here is how I understand your argument: a user doesn’t know where on that supply curve their transaction falls. The transaction may be included after the miner supplied S1 gas in the block, or after S2, S1 < S2. The marginal cost to the miner for including the transaction is respectively 2aS1 and 2aS2, with 2aS1 < 2aS2. If the user sets their tip to 2aS2 but are included at S1, then they are overpaying: the miner would have been satisfied by 2aS1, since it is their marginal cost.
Do you agree that setting your tip to 2aG, where G is the maximum supply of gas a miner can provide in a block, guarantees that you always satisfy the miner marginal cost?
Now, you have not provided evidence why the marginal costs would be increasing (please do if you have it!), but there are reasons to believe that 1 Gwei is an upper bound of 2aG: whatever the location of your transaction on the supply curve, a 1 Gwei per gas unit tip covers my marginal cost. You could probably make the argument in fact that G (the total tips received by the miner if the block is full and tip = 1 gwei per gas) is greater than b + a * G2 (the total cost to the miner of supplying G gas), which would even cover the fixed cost of sending the block empty (if not for 1 Gwei, then for another value close to that).
This value however is residual compared to what users are currently paying in the current system. Users more than cover the marginal cost. The only question is whether they are overpaying compared to some price that would equalise supply and demand in the current market, and the answer is likely that in some cases yes, in others no.
How about in 1559? The price a user pays, P, can be decomposed into basefee B plus the tip T (P = B + T). The miner doesn’t receive B (in the vanilla version), but receives T. Should T be set to 1 Gwei (or an upper bound we are both happy with), the marginal cost MC to the miner is always covered. I think you are claiming that there are cases where MC < T, in which case the user is overpaying. Although this is technically correct, there are three things to keep in mind:
The supply curve is probably close to linear: the more linear it is, the less “room” for tips to deviate from some fixed marginal cost.
Assuming all users converge on an identical “default tip” T Gwei per gas for cases 1. and 3. above, and miners reject any transaction that does not cover at least T, the true overpayment of the user is exactly T - MC, which if point 1 holds, implies T ~ MC.
Let’s assume that MC is fixed for now and look at two situations. In the first, T = MC, users pay the exact marginal cost to the miner, basefee moves to make supply = demand, users are priced at P = B + MC. Second situation, assume that for some reason, users and miners have decided that T* = 10 x MC. At P*, supply = demand. Basefee will always naturally converge to the equilibrium point, so that P* = B* + T*. Users burn less (B* < B) and more is given to miners (T* > T). But P* = P. Users are overpaying the tip (T* > MC) but they aren’t overpaying for inclusion. I’ll allow that should the marginal costs be increasing, and not fixed, then there technically is room for overpaying for inclusion too. But I maintain that this effect is negligible (and all the more negligible the more marginal costs are fixed, which I believe is a good approximation unless proven otherwise), and not a flaw of 1559.
But no one sets their maximum willingness to pay either, this is an important property of pay-as-you-bid mechanisms: they are not incentive compatible.
I don’t think mutually exclusive is necessarily the correct description. I agree with the extreme cases you mention (the rate set at infinity or at zero), but there is no evidence that a happy middle doesn’t exist. You’ll probably counter: no evidence that it exists either afaiac, I don’t think the exact slope of that tradeoff (is it mutually exclusive as you say, or possible to aim for a healthy mix of the two) will be found before deploying. Until then, accumulating evidence that some forces push the tradeoff one way or another. I am enjoying your posts because you provide tangible ways to do so (I like the counterfactual of increasing the block limit for instance), but I don’t have analysis yet (busy writing walls of texts, promise to stop after this one). We should recognise that even then we’ll need to make some assumptions on the demand (how should they react to increased block space vs a change of bidding mechanism?) so an objective measure of how much better/worse things are is probably unattainable. But evidence of what makes some things better/worse, sure.
Here is one: This discussion obscures the way 1559 bidding strategy works, which was well described by @MicahZoltu as “paying the least amount possible at the time of inclusion”. So the “stability” side of the basefee isn’t its more salient component. In case 1. above, we guarantee next-block inclusion at the quoted price. In case 2., we guarantee that your transaction will be considered for inclusion as long as basefee doesn’t top out your max fee (minus the tip). This is more than can be said of the current bidding grammar: you place a single number, and if you are in case 2., since you most likely have not bid your willingness to pay (because who does in this economy??), your chances at inclusion are dimmer than they would be under 1559, unless of course you are nursing your bid, diligently following the latest oracles and replacing as the market moves.
As I understand it, this is not the only way it was described. In the post basefee is also referred to as a consumer tax that arbitrarily adds cost to the item (transaction inclusion), thereby deviating the equilibrium from its natural point. We’ve spoken at length about its dynamics but since its target is the point where supply = demand, I don’t think this interpretation is correct. As a redistributive transfer, sure.
Yes, I don’t rule out the existence of a middle point people may consider provides acceptable results, my point is just that such a middle point is necessarily going to have to make a compromise between the key advantages people are using as justification for EIP-1559, so it seems worth checking that the result is going to measure up against the simpler alternatives based on some quantitative model.
I agree that it won’t be possible to fine-tune the trade-off based on simulations alone, but it would be fairly risky to move to production completely blind without at least some preliminary evidence that such a happy point may exist and where it might be. I think quantitative modeling should at least enable us to come up with upper and lower bounds for the averaging parameter, e.g. by plugging in a wide range of averaging parameters and demand curves and seeing at which point the system starts developing instability – Indeed it would be intractable to search the space of demand curves exhaustively, but one could expect the damping of any oscillations to be mostly determined by the slope of the demand curve to a first order of approximation, so it would be a good start to use a varied enough set of straight lines as demand curve.
I find on the contrary that the “stability” component is essential for “paying the least amount possible at the time of inclusion”. Such an idealized description of the bidding strategy also seems somewhat misleading because the base fee applied to a transaction has nothing to do with the actual demand at the block where the transaction is included, it’s fully determined by the demand during previous blocks, so without a fair stability trade-off the base fee is going to be disproportionately influenced by the demand at the immediately previous block, which is a random variable that might add substantial variance to the price you pay at the time of inclusion. Furthermore, even if one neglects these random block-to-block fluctuations, this mechanism is essentially going to act as an oscillatory system with an equilibrium point at the target demand, and depending on the marginal demand and price level it might take substantial damping to get the system to converge to any particular value (which you can achieve with a weighting parameter closer to the “stability” end of that trade-off I was discussing). Instability is your enemy if you’re trying to pay the least amount possible at the time of inclusion (of course unless you’re trying to game the system and take advantage of the oscillations in order to pay a price below the market price, but then you get to give up any usability benefit ).
I think it’s technically possible for the imposition of a base fee to disturb the equilibrium point between supply and demand, particularly under increasing centralization of hashpower. That said I agree with you that under present conditions it’s unlikely for the base fee to significantly alter the equilibrium point between the supply and demand curve, but only because the hard supply cap causes the supply curve to look pretty close to a vertical line in a neighborhood of the current equilibrium point, so it’s unlikely for a shift up or down to significantly disturb it: However the same can be said about any consumer tax for a good whose supply curve has the same peculiarity, so I don’t think that invalidates @editor-Ajian 's analogy (E.g. compare it with the effect of a government heavily taxing some luxury good with essentially fixed supply, wouldn’t make it less of a tax ).
I know some of the devs here do not look favorably towards GPU miners. But when the time comes to switch to PoS you’ll be better off with a network made up of GPU miners, than a network filled with these ASIC monstrosities.
Since other Ethash-based currencies are worthless, these horrors would become instant paperweights. As such, ASIC miners will have every incentive to delay, derail and prevent PoS. We saw the force of the ASIC propaganda machine when they essentially killed EIP-1057 (ProgPow).
GPU miners, meanwhile, will have other options**.
EIP-1559, as it currently stands, threatens to slash miner profits by making a flawed attempt at hardlining the “minimum necessary issuance” policy through fee burning. Essentially weeding out the (least profitable) hobby miners and promoting a network of large-scale centralized ASIC dominance.
Minimum issuance fosters minimum security.
Keeping a stable issuance, as Ethereum has always had (and EIP-1559 can continue with the ℓ-smoothed mechanism), promotes a healthier, more decentralized, PoS-ready network.
** Mining a different coin, selling the GPUs to gamers / creators / researchers, giving back by doing Folding@Home or similar.
On this I’ll just say that this actually ongoing work, please reach out with you are interested! (I can’t DM here yet because I am new to this forum, but you can also find me on other platforms) We are starting to get some interesting results too.
I’d also like to look at how deployed instances of eip1559 work, with the caveat that their environment differs from Ethereum’s of course (Filecoin and Celo are the two I know of), but it’d be cool to see if that instability is present.
When I say “least amount possible” I mean “least amount possible in the given environment”, not the least amount possible given all possible theoretical environments and frameworks. A user who bids 1 ETH per gas can be confident that they won’t over pay by a significant amount under EIP-1559 unless an attacker burns far more money attacking the system than the user would lose (economic guarantee).
It isn’t about finding the absolute lowest price theoretically possible. It is about giving the user confidence that they are getting a “good” deal without them having to put in a huge amount of work/effort. Yes, they may be able to get a slightly better deal by playing the oscillations, or in a completely different fee system it is possible the fee they would get is lower. However, in 1559 they will get a “fair” and “good” deal regardless of their bid, which is where the UX benefit comes from.
I’m sorry but saying that a system is optimal within the arbitrary limits imposed by that system itself doesn’t seem like an objective way to measure the merit of a proposal nor to understand whether it’s going to do more good or harm to the community, because it’s a purely self-referential statement.
E.g. to pick up your example consider a simplified alternative to this proposal that imposes a fixed base fee of 1 ETH per gas: That’s also the “least amount possible in the given environment”, should give great predictability and usability because it will leave plenty of free room in each block allowing transactions to be included instantly – Still a terrible idea because it fails to optimize any objective notion of transaction gas usage.
That’s only true if the base fee is in itself a good enough approximation of the real market price, which may not be the case for reasons other than an attacker intentionally disturbing the system (E.g. due to the lack of a sufficient stability trade-off as I was describing in the paragraph you quoted). Otherwise, even though individual users may not be overpaying relative to the base fee, they may be overpaying in absolute terms according to any objective definition of what a fair transaction price is.
It seems unlikely that the currently selected algorithm would be so bad at getting close to the real market price that people end up over-paying by significant amounts. If you believe that this is the case, my recommendation would be to draft up a model that shows this. IMO, the usability benefits of EIP-1559 are well worth some small imperfections, especially since we can tune it after it launches once we start getting real world data (data that we cannot get prior to it launching).
I may still be misunderstanding, but I think your argument is basically that we cannot prove the algorithm is perfect right now, so we shouldn’t move forward with it. If that is a correct summary, then my response is that we should not let perfect be the enemy of good. This is doubly true when in order to achieve perfect we first need to gather data using an imperfect system.
The expectation is that this will effectively be the case. When 1559 launches, legacy transactions will continue to be supported. It is likely that at first very few people will be submitting 1559 transactions, which means everything will proceed as normal at first. Over time, as applications and wallets upgrade to add 1559 support we’ll slowly see more and more people using it. If users don’t find it valuable, they’ll simply prefer wallets that let them continue using legacy transaction pricing.
There are many possibilities on what will happen to Ethereum after EIP-1559 is implemented, and the only way to know for sure is to implement it. There are two things I know are certain, investors and miners both want to be paid. Apart from fan boyism, we are both investors, just coming at it from different angles. Miners provide a service, and investors provide an incentive. While it is completely possible that implementation can happen with both parties being happy, it is not the future I see for EIP-1559. My main argument for this is pure financial incentive. Investors do not want to be separated from their money in the form of fees, while miners want to be compensated for the service they provide. At the end of the day, it is not important what currency either party is involved in, they will gravitate to the currencies that work for their own personal use case. I do not mine Ethereum because it is something that I hold an emotional tie to, I mine because it is profitable to do so with the funds and equipment available to myself. If EIP-1559 is implemented, myself, and likely many other miners will migrate to where the new money is coming in. While I do believe Ethereum has reached a point it is so engrained and invested into it is not going anywhere, it does not mean it is safe from the whim of the people supporting it. If for whatever reason there was indication that Ethereum was not going to grow, or even hold its value investors would be running for the hills. It is the same way with myself, if there was indication that mining Ethereum was no longer profitable, I would switch algorithm to whatever was profitable. While there may be enough diehard Ethereum miners to keep the system going, the network performance and security will be greatly degraded. There are already complaints within the community on the slow performance of the network. With an exodus of miners, there would be even less protection from 51% attacks. For example, a mining pool could decide based on the number of miners leaving the network they would have the hashrate to successfully implement a 51% attack. With current complaints of network speed, and precedent set in Ethereum classic of 51% attacks, I do not feel that EIP-1559 will be good for the Ethereum community. Like so many other things in life people are only happy when money is being spent and people are getting paid. I do feel there is room for a middle ground, it will have to be competitive with the rest of the cryptocurrency ecosystem.
Maybe it seems unlikely to you, but I’ve pointed out a number of reasons why this proposal could be disadvantageous to end users, particularly when compared with the simplest possible alternative of increasing block size. Why would it seem unlikely to you that those disadvantages will outweigh the benefits if nobody has bothered to model quantitatively how this proposal compares against the alternatives?
I’m glad to help with that but I don’t think it’s my responsibility to provide evidence that this proposal provides a significant benefit to the community, considering the amount of controversy it has created.
No, my argument was the very opposite of that: I think that it’s not only possible but badly needed to provide some sort of quantitative evidence that this algorithm can perform reasonably against the alternatives.
The first step to do that would be to agree on a more precise definition of what you mean by “improving usability” of the network, otherwise your statement that this is going to have usability benefits well worth the imperfections is fully unfalsifiable. You have repeated half a dozen times that it’s not gas prices that you want to improve with this proposal, but then when I asked you to define “improving usability” more precisely you came back with an answer that basically boils down to minimizing gas prices for a narrow subset of the user base within some constraints on the transaction inclusion delay. Is it just me or that’s a bit of a contradiction?
I agree with you that the onus is on the proposer/champion to convince people that a proposed change will be a net improvement for users. In this case, the majority of people I speak with who fully understand how EIP-1559 works see the benefit it provides. Those that don’t are usually compelled by the illustrative story in https://medium.com/@MicahZoltu/a-tale-of-two-pricing-schemes-dc9c8717906 and other articles.
It is still unclear to me why you don’t find these usability improvements compelling while others do, and perhaps it is because you have some information that others don’t or you recognize a fatal flaw that others do not. However, we have gone back and forth several times and I’m still struggling to see a fatal flaw or new information in your arguments.
You have made a compelling point that over any given window of time gas used will be higher if the base fee ends the window higher than it starts the window, and inversely gas used will be lower if the base fee ends the window lower than it starts the window. This isn’t a point I had previously considered and I do very much appreciate you bringing it to light.
You have also made a compelling point that if the price of ETH declines while the marginal demand (denominated in the thing the ETH price is declining relative to) for block space remains stable, then we will see potentially very large windows of time where the base fee ends significantly higher than it started, which given the above would suggest a net increase in gas used!
I very much value you bringing up both of these points, and I think they are important to consider when evaluating EIP-1559, and we have discussed them a bit on the Ethereum R&D Discord server since you brought them to light. However, I do not personally believe that these points are catastrophic enough to cause the perceived benefits of EIP-1559 to no longer be worth the risk.
Increasing the gas limit guarantees a permanent (until the gas price is changed again) increase in the rate of state growth. Given the points I mentioned above, EIP-1559 introduces the possibility of an increase in the rate of state growth, and that state growth is constrained long term to as long as the price of ETH declines relative to the denominating currency people use for determining marginal utility of transaction inclusion. Also, if the price ever rebounds, the state growth will “undo” itself.
So while both situations have state growth as part of them, the risks of state growth are quite different, which is why I don’t think “just increase the block size” is comparable. Also, as I have mentioned before, I don’t think increasing the block size solves the same problem, but we don’t seem to be able to come to agreement on that and I’m not sure how to resolve that at this point.
I can see why people find that story compelling, I just doubt that it’s the whole truth, it paints a pretty grim picture of the status quo while failing to acknowledge the potential disadvantages of this proposal to end users. It’s not surprising that people find it so convincing but that doesn’t look like a material argument to me.
It wasn’t my intention to point out any fatal flaws so far, nor to get people to rule out this proposal as useless without more careful consideration. The points you are referring to above regarding the connection between major price changes and state growth weren’t intended to show any sort of catastrophic flaw, but simply as an example demonstrating that the effect of this proposal on state growth is far less deterministic than people seem to think.
I think the key point I have raised is that there is some potential for this proposal to increase the gas prices that a significant portion of the user base are paying today. The assumption that this is going to improve usability relies on this mechanism not frequently reverting back to a first-price auction of miner tips (which requires BASE_FEE_MAX_CHANGE_DENOMINATOR to be low enough), and on the base fee being a stable and accurate approximation of the real market price (which requires BASE_FEE_MAX_CHANGE_DENOMINATOR to be high enough). Whether that’s going to be the case for any value of BASE_FEE_MAX_CHANGE_DENOMINATOR to a degree satisfactory to most users is still unknown, and judging from the information we have so far it might very well be that a small increase in the block gas limits delivers a usability improvement superior to this proposal.
To me the question is whether having a large confidence interval on the long-term state growth is better or worse than a small confidence interval with some certain but minor state growth. I’d argue that if the latter can be shown to provide greater benefits to the user base or if (as you were arguing before) exceeding a certain threshold of state growth for an extended period of time were to lead to unmanageable consequences to the network, the solution with the smaller confidence interval should be preferred.
That should be approximately the case, but not quite. The base fee adjustment formula proposed here is not fully path-independent, so there will always be some minor but permanent state growth with this proposal even if the base fee returns to the same level as it was before. Quantifying it isn’t straightforward without knowing the frequency and amplitude of such price oscillations beforehand, so we are still left with some significant uncertainty in the long-term state growth with this proposal, even under the unlikely assumption that the ETH price will always keep coming back to the initial level.
I think that the root of that disagreement is the lack of an objective, quantifiable definition of “improving usability”. So, what is the problem that this proposal is trying to solve, in quantifiable terms?