RT @econoar: While everyone is fretting over a PoW algorithm that’ll have no relevance in 5 years...
Let’s focus on EIP-1559. It would allow us to fix the inefficient fee market, make Ethereum more user friendly, kill economic abstraction and lower total issuance %.
I'm not sure I buy the rationale here. If the goal is to help users avoid overpaying, that seems like something that should be a client-side solution. There doesn't seem to be sufficient cause to risk the protocol here. Every change is a risk. At the very least, we should wait for PoS and see what that does to the market before changing the way fees are calculated. If we have to change the way fees work, we should do everything we can to try to make it the last time.
Further, I'm not sure this is a reliable fix for the problem. It's just obfuscating the system. Spots in the block are still going to be auctioned off, it's just through the tips instead of gas fees. The burned BASEFEE seems like it would just motivate miners to ignore anyone who doesn't provide a tip. This could easily end up increasing the transaction cost for users as they now have to pay the BASEFEE too, but miners won't consider it when deciding which transactions to include. This is the opposite of the stated goal.
I saw that Vitalik's paper was linked in the article, but I haven't had time to read it. Maybe I'm missing some crucial details here, but from my understanding of the medium article this doesn't sound like the right move at this point. In addition to the technical risks, the economic impact could also potentially backfire. It seems like a lot of risk for uncertain gains.
Agree with most; would like to clarify on:
> The burned BASEFEE seems like it would just motivate miners to ignore anyone who doesn't provide a tip.
It would motivate miners to ignore the low-fee transactions until `BASEFEE` drops "sufficiently" - then, the transactions can be re-considered. There's no way of not providing a tip (except not providing a fee at all, too).
Thanks for the correction.
If the tip isn't optional, then this just seems like obfuscation. Complexity without purpose. From the user's view, the fee is just as unpredictable as before, they'll be just as reliant on client-side tools to figure out transaction costs, and now they have to understand the BASEFEE and tip concepts. This might make it slightly easier to build tools to guide users through transaction costs, but this doesn't enable any use cases that weren't possible before.
Pretty easy to see. The logic behind this proposed feature assumes miners always select the most lucrative transactions, full stop. It does not explain what we see in the wild, which includes empty or partially filled blocks with a transaction backlog.
The reason for this strange behavior by miners is that there is an actual cost to a PoW miner to include a transaction, and that cost depends on the processing power expended. That cost is the time it takes to figure out what goes in the block. This time represents a small but non-negligible handicap in the race to solve the next block. So the more transactions (opcodes) a miner processes, the less likely they are to solve the block versus an adversary who solve an empty block. It's not much, but milliseconds can make the difference between a block-reward and an uncle-reward.
Under the proposal, miners would be better off mining empty blocks then mining full blocks at basefee.
So of course what will happens is that nobody's transactions will ever be processed at basefee, and transactions will only be processed at basefee+premium. Which is what we have now, except "basefee is 0"... it's 0+premium.
Since the premium part depends entirely on factors that cannot be known at the time the transaction is submitted, which is precisely the situation we have today all that we do by adding basefee is reducing the percentage variability, but the absolute variability will remain. Because all of the same factors remain. So premium will be the same.
In other words, we will increase the total cost of transaction because the variable component of the economics will persist on top of the fixed component.
So the economics of this proposal are negative in PoW. In PoS, miners have no cost difference between a full block and an empty block, so miners should be penalized if they don't include a full block.
> The reason for this strange behavior by miners is that there is an actual cost to a PoW miner to include a transaction, and that cost depends on the processing power expended. That cost is the *time* it takes to figure out what goes in the block. This time represents a small but non-negligible handicap in the race to solve the next block. So the more transactions (opcodes) a miner processes, the less likely they are to solve the block versus an adversary who solve an empty block. It's not much, but milliseconds can make the difference between a block-reward and an uncle-reward.
This is what the tip is supposed to cover. That said, I [ran the numbers this morning](https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783/16) and the required tip to compensate for uncle rate risk is actually quite small; 0.4 gwei assuming aggressive estimates for uncle rate risk and 3.3 gwei assuming maximally conservative estimates.
The tip has to cover:
(a) the miner's temporal opportunity cost
(b) the miner's transaction-fee opportunity cost.
(a) is likely to have some measurable amount, and I already addressed that. The part (b) is what the miner knows absolutely, but the person submitting the transaction does not, and can not know...
This lack of information creates a volatile risk premium that must be added to the tip. The volatility is not something you can calculate, because it depends not only on the urgency of whoever submitted the transaction (which is highly variable), but also on their belief of the urgency of everyone else who might be submitting transactions.
> (b) the miner's transaction-fee opportunity cost
The point of the proposal is that most of the time the transaction fee opportunity cost will be zero, because blocks are on average only half full. The fact that (b) moves from being a very volatile unknown to being usually zero and hence much more predictable is precisely where the efficiency gains of the proposal come from.
>the point of the proposal is that most of the time the transaction fee opportunity cost will be zero
Unfortunately, bandwidth is not infinite, and there is significant risk that the rest of the time the opportunity cost is non-zero.
Even more unfortunately, we can't predict at the time of submitting a transaction that our transaction won't get tangled up in one of those times. Nor can we predict what everyone else who is about to submit a transaction is about to predict. Nor is each of our needs with respect to settlement duration equal. So we have an unknown and unknowable and unbounded risk when we choose what "tip" to add to our transaction fee. Which each of us calculates according to our risk profile. Presto.. volatility.
This is the variable component here: not the average opportunity cost [edit: of the miner who mines our block], but the black-swan (or in the case of Ethereum, flock of off-white swans) opportunity cost [edit: from which we are protecting ourselves when we submit the transaction with the tip!]. There is a risk premium that is worth being paid.
>... opportunity cost will be zero, because blocks are on average only half full.
History tells us this is not true. During periods when blocks have been less than half full, we still saw huge volatility in the "tip" offered to miners in the form of gas ~~price~~ [edit: fees].
You are falling into the trap of using perfect knowledge in disguise as averages in a situation where individuals make unique risk-pricing decisions with distinctly imperfect knowledge.
It's true that in cases of sudden spikes of sufficient size opportunity cost is nonzero, but:
1. A user that submits only a nominal tip and unluckily lands during a congestion spike can simply wait until the congestion spike ends (this happens already in the current system, but in this system it would be less bad because congestion spikes get relieved much more quickly due to (i) the 2x higher block size cap and (ii) the basefee quickly catching up to the new usage level). A user that is willing to wait long enough experiences the game as an ascending price auction (which is efficient).
2. The magnitude of volatility is still expected to be much lower on average, because a large portion of txfee volatility gets converted into block size volatility, and so even if it becomes theoretically optimal to use complex techniques to second-guess people, the penalty for using suboptimal techniques would be several times lower.
I'm not positing perfect knowledge, I'm positing arguments for why the proposed scheme offers large mitigations relative to the status quo.
There you go again: "on average". Volatility isn't about the average, it's about standard deviation.
We can take this apart because of a really neat feature of Ethereum network, which is that while many users transact frequently, most users do not. Thus each day of transaction history aproximates sampling-with-replacement of the actual user behavior.
First, transactions have a distinctly nonlinear inter-arrival rate... easy to see: https://etherscan.io/chart/pendingtx
It is noisy: the left hand side of the chart is not predictive of the right hand side of the chart (it changes day to day as you click on it, but the statement above will be true regardless).
So we can treat it as high-frequency noise superimposed on a background average signal which is a solved problem. The proposed algorithm for basefee is a highpass filter, but the noise is high frequency. So right away you can see the problem: you can't address high frequency noise with a highpass filter!
For those who like graphs, it will be more obvious when you graph gas fees ( https://etherscan.io/chart/transactionfee ) versus network utilization ( https://etherscan.io/chart/networkutilization )
These figures are on a daily basis, but the cool part is that it is sampling with replacement. So even two days with the same utilization will contain a different mix of transactors and therefore we can tease out the distribution of transactors!
A scatter plot is interesting: a widening funnel as utilization increases. Of note, no day has had more than 97% utilization, and only 18% of days have more than 85% utilization. The network does bump up against capacity, but doesn't stay there for long. nevertheless, not only are gas fees volatile within a day, they are volatile between days! Even during the vast majority of days where the network has more than 15% spare capacity!
If you graph the average gas fee by 2% cohort of utilization (utilization = 2%, 4%, 6%... 98%, 100%) , it's easy to see that this is quite nicely linear for low utilization, becoming distinctly nonlinear at high utilization. The linear part is because for 1/N of a block you get 1/N of the fees, which is obvious. The nonlinear part is exactly what you expect from basic queuing theory and an avalanche into escalating delays at higher utilization. Clearly people are willing to pay more to avoid being delayed, and as the probability of being delayed increases, miners are able to extract higher average transaction fees. This is essentially what you are mitigating by the basefee component which is a function of the long-term average utilization.
But that is the average. Where things get interesting is looking deeper. If you graph *standard deviation* by utilization, it is *also* exponentially increasing! Another way to see this without resorting to cohot analysis is the humble scatter plot, which reveals a widening spread.
The math is simple... At any utilization, there is a decreasing probability that a transaction will be delayed by 1, 2, 3... K blocks, and the sum of the probabilities for all values of K is 1.00.
As utilization increases, with a random transaction inter-arrival rate, the probability that a transaction will experience K or more blocks of delay is the sum of the residuals of this series, which queuing theory tells us increases exponentially with utilization.
On a per transaction basis, all transactors have some K for which K blocks of delay is intolerable. However, not all transactors have the same K.
Thus, as utilization increases, the folks who can wait out the higher K's begin to have sufficient risk that they too will be delayed, and they too are willing to pay more.
In other words, as utilization increases, not only are people on *average* willing to pay more to process a transaction (which the basefee addresses), but the spread between what the individuals are willing to pay also increases.
Under the proposal OP advocates, the basefee will converge to the average that users are willing to pay, and the tip will converge on the standard deviation. Which is where the bulk of the volatility lies on an intraday basis, and on an inter-day basis.
So the assertion that OP's proposal will remove the majority of volatility is wrong. It will only remove the majority of volatility at low utilization. Which is precisely where we don't have the problem.
Even if the decreases in volatility don't matter much because "it's all in the fat tails", argument (1) above still stands. Looking at the spikes [in your linked chart](https://etherscan.io/chart/pendingtx), each sudden spike is only at most ~5k transactions, and if these transactions are like regular transactions (ie. ~70k gas each) then that could be cleared in 22 16-million-gas blocks (ie. ~5 minutes). So a transaction setting a low fixed tip without regard for network conditions would at most just get delayed by 5 minutes.
>if these transactions are like regular transactions (ie. ~70k gas each) then that could be cleared in 22 16-million-gas blocks (ie. ~5 minutes)
350 M gas... That spike will take all of the gas in 22 of those 16 million gas blocks. So will have to compete with whatever background transactions are arriving. If these are spikes occur while we are at 80% capacity on 8M gas blocks, and we jam suddenly up to 16M blocks, then it will take 36 blocks, not 22 blocks.
And meanwhile the basefee will be ticking upwards. So what happens to a transaction that calculated its total gas based on the basefee that used to exist? Clearly the tip they thought they were offering will be reduced. So they will be stuck further behind any new transactions that leave the same tip, but on the adjusted basefee.
And there's more. In order to clear this backlog quickly, miners have to accept a lower tip, because by clearing the backlog they increase the basefee, which reduces their share of any tips waiting in the backlog. Which, if they are smart, they aren't going to do. Miners are collectively better off leaving the transaction in the pool and only using the residual capacity under 8M gas so that they can squeeze out the most tip. So no, I don't think it's going to work the way you think its' going to work. The volatility risk remains, and the incentives are wrong.
You need an incentive to miners to clear backlog as quickly as possible, not maximize the backlog.
> So will have to compete with whatever background transactions are arriving. If these are spikes occur while we are at 80% capacity on 8M gas blocks, and we jam suddenly up to 16M blocks, then it will take 36 blocks, not 22 blocks.
This is true, though note that it'll take a shorter amount of time in prac
> And meanwhile the basefee will be ticking upwards. So what happens to a transaction that calculated its total gas based on the basefee that used to exist?
The transaction sets a `MAX_BASEFEE` which is equal to the maximum the sender would be willing to pay to get it included. Whatever the fee is, that's the fee that gets paid. The one case this could lead to complications is if someone is trying to send _all_ of their ETH from one account to another, in which case a small amount of dust would remain in the sender account, but that's a relatively rare case.
> And there's more. In order to clear this backlog quickly, miners have to accept a lower tip, because by clearing the backlog they increase the basefee, which reduces their share of any tips waiting in the backlog. Which, if they are smart, they aren't going to do. Miners are collectively better off leaving the transaction in the pool and only using the residual capacity under 8M gas so that they can squeeze out the most tip. So no, I don't think it's going to work the way you think its' going to work. The volatility risk remains, and the incentives are wrong.
This is all assuming that miners are colluding, and if they are, there are far meaner things they can do, even under the current system (eg. they could vote the gas limit down to whatever level pushes gasprices up to 20-30 gwei to extract more profits for themslves).
To be clear, your proposed strategy is: miners all collude to only accept 7m gas per block, and drop the BASEFEE to zero, and then demand a high tip? If so, another thing worth noting is that miners' revenue would just be equivalent to whatever they can get employing that exact strategy today, so even under total collusion it's not making anything worse. If the charge is that it increases _incentives_ to collude, we can mitigate that by putting the BASEFEE into an account that distributes 0.1% of the funds in the account to the proposer of each block.
I see that.
The uncle risk per extra computation that currently exists is already being compensated by miners mining incomplete blocks... so you are measuring the current inefficiency, not the full opportunity. I am not surprised you would find the current inefficiency to be quite small. But that does not mean the complete opportunity is that small.
Second, to miners, the basefee is an invariant. We will get the same choice-behavior if basefee=10 versus 11 because this is the part that miners don't ~~see~~ [edit: care about]. Therefore, we should expect the same *absolute* variability in transaction pricing accepted by miners if basefree=10 versus 11.
In other words, miner behavior now is exactly what we should expect it to be with basefee=0 (or anything else) if we substitute gasprice variability that we currently have with tip variability that we will have.
This isn’t true. You’re ignoring the fact that the base fee compensates for demand which is the inefficient part of today’s pricing.
I won’t rehash it here but explained it further in the Ethereum magicians thread if you want to check it out.
You are forgetting that it is the miners who choose the transactions, not the transaction submitters. You can submit as many transactions as you like, but if the miners don't include them, they are just backlog. Basefee is irrelevant to miners, because it is burned.
I agree with you that TX will need a slight fee over the base but because the base accounts for capacity, it won’t be a bidding market like it is now. The market will settle on a flat fee and it’ll be minimal.
The cost to miners to propose a block TX is very negligible, the real cost is on the network as a whole for processing and storing. Most pricing today is due to market inefficiencies in keeping capacity the same all the time despite demand.
> The market will settle on a flat fee and it’ll be minimal.
Based on what evidence? The entire history of ETH is exactly the opposite: the market settles on a highly variable, non-flat fee, and it is not minimal.
If by "the market" you mean PoW miners, in fact you are wrong. Miners do (and will continue to) select the transactions that net them the most income. To them, basefee is irrelevant because it is burned, so it neither adds nor subtracts to their behavior. They will *only* look at the part that matters to them, which is the premium above basefee.
This is identical to the situation we have today, which is a basefee of 0, plus a variable component.
>Most pricing today is due to market inefficiencies
This part is true. However, it's too glib.
The inefficiencies that create transaction pricing variability are due to opacity of the bids that everyone else is making to miners: you don't know that someone isn't going to outbid you. So you bid higher than you would have needed to bid if you had more information.
Also, the queue is not ordered and transactions are delayed, so even if you had perfect information, if facts change after you submit your transaction, you can be outbid. Thus, transactions are over-bid to compensate for this information risk.
Basefee does not change this. Since basefee is irrelevant to miners, they will ignore it, and choose transactions that benefit them the most. So they will choose the transactions that have the most tips, which is exactly the same level of entirely opaque for exactly the same reasons.
So you have exactly the same opacity, exactly the same motivation, and thus exactly the same inefficiencies, PLUS the added basefee, which is only relevant to those who submit transactions, and irrelevant to miners.
In other words, all you will do with this proposal is increase the cost of transacting to end-users.
Also, it doesn't work. Anyone can look at the transaction queue just before they submit their transaction and know exactly what everyone else is paying. They can do that today. That wouldn't do any good however because it doesn't predict what the folks after you are going to submit.
The fundamental inefficiencies are not because we don't know what the price should have been, but because it's technically impossible to know what the bid price will be. You can't create a deterministic market-pricing system where price is responsive to instantaneous demand and where supply and demand are (a) non-ordered, and (b) time-skewed. Not without a functioning time-machine.
You’re still not listening to me though. Basefee adjusts based on capacity. That is the entire crux of this and you keep ignoring me saying it. Anyways move to discussion to Ethereum magicians if you want as like I said we have already discussed this there.
And you all came to the same incorrect conclusion there.
This is one of the many reasons I was against the creation of the "magicians" forum. It was doomed to be an echo chamber from the start, because of how it was created--and now you're starting to see the effects of that (if the Afri thing didn't drive the point home hard enough, that is).
You aren't listening to me either. Basefee merely acts on those who submit transactions, but not on those who ultimately include them. It has no beneficial impact on reducing inefficiencies in the choice of transaction price. These inefficiencies are not an artifact of the past (and therefore computationally solvable), but of the interval from when a transaction is submitted, and when it is processed, and what else is submitted in between. You cannot know information that you cannot yet possess.
Additionally, these efficiencies are not linear, or as simple as the theory makes them out to be. Miners make choices at the time a block is solved, which is shifted in time from when transactions are submitted. And their reasoning is not as simple as the theory makes them out to be. For example, they clearly do not make choices merely to maximize the gas fees. Otherwise you would never see empty blocks. Or blocks below the gas limit. But of course we do. And the transaction backlog is never zero. Which means there is already a backlog and a capacity shortfall. Which means that the basic theory is at least inadequate, if not entirely wrong. Sorry if I'm not shifting over to magicians, but you posted your incorrect article here, and I prefer to address it here.
> Sorry if I'm not shifting over to magicians, but you posted your incorrect article here, and I prefer to address it here.
I, for one, prefer _more_ venues of discussion, so more people can be engaged.
It wouldn't do well to split the argument all of a sudden. You've presented your point quite concisely; it makes more sense to link _back here_ from EM.
The team is currently getting ready for the next hardfork, which will take place in about eight months from now. According to reports, this hardfork could also include the proposal made for Constantinople hardfork, and the estimated deadline to submit all the proposals for Istanbul is slated to be May 2019.
However, July 2019 would see the soft implementation of Istanbul compatibility on all Ethereum clients and August 2019 is the estimated timeline for the Testnet upgrade. Finally, the hardfork is expected to go live in the month of October, 2019.
Right, raising fees. If the reason why the gasused is going above 8mn is not simply a short-term spike in demand but instead is actual net average increased real usage, the average fee will rise and the usecases that rely on lower fees will eventually be priced out because the fees will not drop back low enough for them to begin functioning on the network again.
This sounds like basically a less-bad version of the trainwreck that is coming to hit Bitcoin Core soon. But it is a trainwreck that Ethereum doesn't currently face because miners can raise the gaslimit in response to increased adoption, technological improvements, uncle/orphan rate improvements, etc.
The proposal to switch to this BASEFEE model is logically separable from the question of whether the gas limit is hardcoded vs set by miners. I don't think the intent was to advocate changing what mechanism the gas limit is set by; what matters is that it goes up to 16 million somehow.
> I don't think the intent was to advocate changing what mechanism the gas limit is set by; what matters is that it goes up to 16 million somehow.
Edit: re-read some things.
Hm, isn't the point of the 16m number just so that the capacity limits can flex up and down as human behavior changes demands on daily/weekly cycles?
> the other option is that miners just vote the gas limit up to 16 million.
So then this becomes voted on and can increase as adoption does?
A key advantage (to me) for Ethereum today is that as the economy changes and adoption grows, miners are able to quickly react and raise the capacity limits to keep up with the adoption. I would be surprised if the capacity demands on Ethereum aren't at least double today's demands in two years.
Lastly, what about the problem of paying for security (even under proof of stake) while limiting inflation, preferably also considering a 120 million Ethereum cap? If fees are being burned and stakers must be paid, that seems to exclude the possibility of a system that isn't inflating constantly.
> If fees are being burned and stakers must be paid, that seems to exclude the possibility of a system that isn't inflating constantly.
How so? Fees being burned makes a fixed supply _more_ feasible, because you could instead of burning the fees save them in a reward pool that gets distributed among the next 1 year's validators.
> So then this becomes voted on and can increase as adoption does?
Yes, just like today. The goal of the proposal that Eric's post is about is not to change that, it's to effectively replace the 8m cap with an 8m target; the target could be voted on the same way the cap is today.
> How so? Fees being burned makes a fixed supply more feasible, because you could instead of burning the fees save them in a reward pool that gets distributed among the next 1 year's validators.
Rewarding this year's fees next year vs rewarding them now doesn't make much of a difference to me. But I believed that the way the EIP was written, the fees were simply burned, so I was responding to that. I'd actually prefer that they cycle faster like within a month or so, but any form of cycling is fine.
> Yes, just like today. The goal of the proposal that Eric's post is about is not to change that,
Target doesn't become public knowledge though, does it? I.e., it is just a miner setting? Also the EIP describes replacing the GASLIMIT field; How is the true gaslimit voted on / tracked / adjusted then?
I guess where the confusion is coming from is I'm trying to understand how the implementation details **won't** affect these things. Philosophically knowing that the fundamentals I'm concerned about (Dynamic blocksize, fees cycling back to pay for security) makes me more in favor of this change, but the EIP as written seems to imply otherwise so I don't see exactly how the gap will close. :/
> Target doesn't become public knowledge though, does it? I.e., it is just a miner setting? Also the EIP describes replacing the GASLIMIT field; How is the true gaslimit voted on / tracked / adjusted then?
Ah, you are right that the EIP as written removes the GASLIMIT field; so the gas limit would be fixed. However, the implicit target could be voted on by miners, to any value between 0 and the full gas limit, so there would still be room for adjustment.
I think leaving unlimited room for easy upward adjustment is less important than it was before, because at this point the gas limit is limited by technical constraints, so it would only make sense to bump it up in concert with other hard forks that improve efficiency in different ways. But if desired, we could just have both fields in the block; it would just make the fork harder because it would require adding a new field and thus changing the structure, as opposed to reusing an existing field.
Why aren't there miners out there running their own nodes that vow to pick up cheaper tx's? I know I would certainly choose to use those nodes and they would probably end up earning more by getting more tx's..
Seems there is a misunderstanding. You can broadcast your transaction to any node, and the node will quickly tell the rest of the network about it. This is the "pending pool" of transactions, which haven't been picked up yet
Every 15 sec (on average), the miner who won the proof of work race for the block gets to pick which transactions from the pending pool get accepted. Big miners get most of the blocks
Most miners are willing to accept a price as low as 1Gwei, but they obviously all choose to pick higher fees when available.
Look, it's not that cheap to be a miner, and profits are tighter than ever. They kinda have to pick high fee transactions to make sure they survive. I would too
ah ok. I thought the pending pool was held on the nodes? So a miner could have a preferred node. And yes, I fully understand the basic market dynamics of it all. I just thought there might be a niche of choosing a node if that somehow promised cheaper tx's if a miner was able to dedicate to using that node... therefore potentially getting more transactions. But I guess my theory wouldnt work since it cant work like that.
More small miners won't help.
Bigger miners have a bigger chance of mining a block.
Whoever "mines" the block get's to decide what txs to include.
Small miners probably won't have much chance. You can't "choose" who mines your tx.
You can choose how you submit it to the network but that's a different thing.
Usually, miners select transactions ranked by the highest fees which results in many users grossly overpaying. Had they known what others were bidding, they could avoid making bids that were much higher than necessary.
Yeah, thanks Metamask for your glorious UI update that does everything it can to hide Gwei cost and therefore having users paying more than necessary most of the time.
Showing gwei isn't user friendly at all. I understand with the system we have now, it's necessary to have the choice. But most regular users shouldn't ever hear or see the words blockchain, gwei, gas, transaction. Interaction should be seamless
If we are spending in ETH then does it not make sense to show the cost in ETH first and foremost? I understand the reasons why the change has been made to cater to the new world of users but it still makes more sense to a lot of people to show whether the current network standard is 1 gwei (cheap), 5 gwei (reasonable), 10 gwei (network is busy and getting expensive), 20 gwei (ridiculous)... because when you only compare dollar amount and you are interacting with multiple dapps, you have no idea whether the dapp interaction or the network is cheap or expensive thanks to this information being hidden.
Edit: What I'm trying to say is that the ETH cost of the interaction doesnt change, only the speed of the network and what is the minimum/standard gwei to use. As opposed to a dollar amount which fluctuates on a mixture of contract cost and network speed. It's actually more complicated.
Currently, it’s technically possible to pay fees in other tokens if you want but it’s logistically tough and in most cases more expensive.
This would cement ETH usage at the base layer forever as ETH must be burned.
Let me get your thoughts on this:
My solution to the gas price estimation is simple and solved at the wallet level. When a user confirms a transaction with a wallet they agree to a "maximum fee" that is more than enough to process the transaction quickly and specify the timeline they want the transaction processed in (< 5 minutes, 30 minutes, an hour). The wallet then signs the transaction with the lowest possible gas price based on current gas price data and submits the transaction.
Then the wallet waits, and if the transaction is not processed in a few blocks then the wallet automatically (without user interaction) increases the gas price and resubmits the transaction. This process is repeated until the maximum fee is reached, essentially guaranteeing efficient gas price discovery and seamless processing of the transaction that will only get stuck in the event of a cryptokitties-esque market influx.
Could potentially work but requires a lot of interaction among all the wallet providers to come up with a single UX for this.
Or, we could basically just do exactly what you're describing at the protocol level + more! :)
Probably not, but something that changes the miners revenue can result in a highly contentious fork. This is 100% solvable off-chain so I don't see why we use that solution instead of mucking about with core?
There are benefits to this well beyond optimal gas pricing. It adjusts capacity of the network based on demand and it kills economic abstraction at the base layer due to burning eth, which in turn helps the value of ETH.