EIP-1559: Fee market change for ETH 1.0 chain

EIPs
,
#78

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.

4 Likes
#79

I half agree with you. Rather, in the abstract I completely agree with your logic, but my practical experience in working with this EIP leads me to believe that separating it out along the lines you’re suggesting would do both of the EIPs a disservice. I don’t see a good way of navigating the politics, the current EIP is difficult enough :slight_smile:

#80

Can you elaborate on the problems you see with the PR I submitted? To me, it seemed pretty simple to disconnect the change in block sizing from 1559. The only impacted section was the slow migration from old gas pool to new gas pool, but that ended up not being very hard to modify to achieve the goal of no change to miner-voted block sizing.

2 Likes
#81

I have published a new EIP for Typed Transaction Envelope (https://eips.ethereum.org/EIPS/eip-2718) which enables us to add new transaction types to Ethereum without having to carefully tip-toe around backward compatibility. If that EIP finalizes before this one, then I recommend updating this to use it.

Transaction Type 0 will be a wrapper for legacy transactions, and EIP-2711 is tentatively going to be using type 1, so we can make this type 2 (we can choose any number, though < 55 saves us some bytes on the wire due to the nature of RLP encoding).

2 Likes
#82

Can someone tell me why miners would include transactions without a tip if the fee gets burned and larger blocks will just slightly up orphans? It looks to me like most miners wouldnt need to actually put transactions into blocks and would only do ones with tips. If enough miners do this then most transactions would just be prioritised by gas price and as usage goes up the fee market will just be the same as now as only tip transactions get pushed.

1 Like
#83

Answered in Discord, but for continuity answering here as well:
Miners won’t accept transactions without a tip (at least not profit seeking rational ones that aren’t getting paid some other way).

1 Like
#84

My issue is just that it slows down the process. If you want to break EIP-1559 into smaller chunks, that’s great, but given the current political climate that seems like it would slow the deployment. I would be elated if I was proven wrong about this by someone else trying it out. :slight_smile:

#85

Usually splitting things up into smaller more manageable chunks facilitates moving things through more quickly because people can focus their efforts on the pieces they care about, and you don’t end up with one contentious piece holding everything else up. Do you believe that isn’t the case for Ethereum hard fork inclusion stuff? If not, do you have any idea why that isn’t the case?

#86

Just saw your comment @vbuterin

IMG_20200722_105546
IMG_20200722_1055461038×980 186 KB

Could you lay out the thought how eip-1559 helps with the attack described in the paper? I was thinking about the impact myself but concluded that because the anticipated equilibrium in https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf has only half filled blocks it would keep the MINFEE at 0 and hence not change anything on the problem.

There was another paper proposing payout of the transaction fee in a sliding average window of the last 10 blocks. That might fix the risk of the petty miner scheme and could be quick follow of 1559.

#87

I’ll let someone else give the more complete response, but the gist of it is that 1559 burns congestion-related fees, thus miners would not profit from reorgs for fees.

If MINFEE is 0 then the system either is broken or demand for using Ethereum is legitimately low (which we haven’t seen for quite a while and seems unlikely to happen soon). Equilibrium for 1559 is half full blocks, but under the assumption of raw demand for Ethereum block space being greater than supply of block space. It is the fee going above 0 that drives final demand down to equal with 50% of block space supply.

1 Like
#88

Yes problably broken is the right description or at least manipulated. I’m quoting from the mining_CCS.pdf paper, highlights by me:

Once any non-zero fraction of miners is PettyCompliant, it enables various strategies that are more aggressive and harmful to Bitcoin consensus. We call this the undercut-ting attack, where miners will actively fork the head of the chain and leave transactions unclaimed in the hope of incentivizing PettyCompliant miners to build on their block. In some scenarios, our simulation reveals a non-equilibrium with increasingly aggressive undercutting. But with an expanded strategy space, and suitable assumptions, we are able to prove that an equilibrium exists. However, it is one where miners include only a fraction of available transactions into their blocks. This results in a backlog of transactions whose size grows indefinitely with time. We confirm this result using simulation.

So when miners include only a fraction of available transactions into their blocks then my understanding is MINFEE would stay 0. It’s misbehavior, but misbehavior that might turn out to be more profitable to the miners.

#89

This isn’t true. With 1559, MINFEE would be 0 only if a plurality of miners (exact portion changes depending on how much they sacrifice, but it can be as high as over 50%) all sacrifice profits in order to drive the fee down. As long as they do this, any miner that defects from this strategy will be more profitable than miners executing the attack as long as the attack continues. When the attack is no longer executed by a sufficient portion of miners, the base fee will rise back up to its correct level.

This means that any miner that defects from the attack is rewarded, and any miner that participates in the attack is punished for as long as the attack is ongoing. Also, we can adjust the portion necessary to successfully drive the base fee down by increasing the block size target. Current EIP specifies the target as being “half full” but we could just as easily target 1/4 full which would increase the hashing power required to attack the system in this way by ~2x. The only downside of that is that we end up with bigger block size spikes and it is unclear how various client implementations will handle that so we are starting with only a 2x block size spike being possible.

Something to keep in mind is that a 1559-like fee system is sufficiently different from the system the paper is attacking that the attack no longer makes sense. Because of this, outcomes from that paper cannot be applied to a 1559-like system directly. If you want to describe an attack against a 1559-like system, you will need to fully describe a new attack.

Imagine the situation “When X = 1 and Y = 2 then X+Y = 3”. If you change X to equal 5, the conclusions that X+Y=5 no longer holds and you will need to re-evaluate things. In this case, the paper is built on the premise that fees are allocated in a very specific way, and when you remove that premise the rest of the paper no longer falls out.

Note: It is certainly possible that an outcome like the one described in that paper is possible, but I believe it would need a pretty significant rework to draw that conclusion.

2 Likes
#90

Maybe this would help killing this bad equilibrium

Can’t find the paper anymore but I read an idea about creating a FEEPOOL. All spend transaction fees would be added to the FEEPOOL, and a block miner would receive 1/8th of that FEEPOOL for a new block. The MINFEE would stay and guide users to pay more when there is congestion, while miners would be incentivized keep blocks filled so the FEEPOOL stays high and miners would be less worried about tricking the previous or next block for transactions as their fee based revenue is less spiky. In fact miners could be incentivized more since I think burning fees below MINFEE would not be needed in this case and could just be added to the FEEPOOL…

#91

The paper is saying the opposite. Miners are incentivized to drive the fees up, but drive the MINFEE down, so that the tip maximizes. When a miner creates a filled block that has a higher MINFEE then that creates an incentive for all other miners to ignore this block as it reduces all future revenue from transactions. In fact the incentive to game the system gets bigger.

E.g. for Spark Pool and Ethermine each step higher MINFEE would mean to surrender future transaction profits on their 29% / 20% share of all blocks.
Selection_199

True, I was just curious which aspect of 1559 specifically is the part that is disabling the mentioned attack as twittered by Vitalik. For me it seems 1559 in it’s current form incentivizes the attack even more.

– We have posted nearly at the same time, so see my previous post for a patch proposal on EIP-1559 to remove the gaming incentive.

1 Like
#92

This has been discussed here in this thread I believe. I forget what the arguments against it are but I think it was just something like, “why miners instead of everyone?”

The paper wasn’t about 1559 either. :slight_smile:

If a miner controls 51% of hashing power then they can do some pretty bad things to Ethereum, including simply ignoring all other miner blocks to maximize their block reward. 1559 doesn’t really change that in any meaningful way, and if someone wants to exploit 51% of hashing power for financial gains there are far more efficient ways to do so than driving the fee down. Something to keep in mind is that this sort of attack is collusion resistant because there is a financial incentive to defect, and you can defect anonymously. Because of this, it is very hard for miners to collude to execute the attack.

As far as mining pools go, keep in mind that any mining pool that is executing this attack will become less profitable than a mining pool that doesn’t execute the attack, which means pool participants can (and potentially will) individually defect if a mining pool is detected to be executing an attack like this.

It is the fee burning aspect that does it.

1 Like
#93

Thanks for the discussion @MicahZoltu , it’s good to keep the ball moving here. Very curious about the impact of EIP-1559 on the fee market once it’s deployed. If there are side-effects fixes such as FEEPOOL can still be discussed then.

1 Like
#94

Shall we set the denominator to 8 for the downward movement and 7 for the upward movement to make the rate of change the same in both directions?

#95

I’m not opposed, though there is a desire to limit non-critical consensus changes to the specification that you’ll need to push past, which I suspect will require an argument as to why we should care other than “because symmetry feels good”. :slight_smile:

#96

Blog post that hopefully can help dispel some fear over 51% attacks against EIP-1559: https://medium.com/@MicahZoltu/eip-1559-51-attacks-should-you-live-in-fear-d817be3759dc?sk=59773d28b15446bacd5e5112e350e000

1 Like
#97

@dominic one major part of EIP 1559 that mitigates the attack is the part where the fact that fees are burned makes it economically safe to retain some issuance, which pushes the chain away from the fee-dominated world that the article describes. Additionally, the fee burn makes transactions themselves less profitable to include, compounding this effect.

Partially filled blocks don’t necessarily cut the MINFEE to zero; that would require average blocks to be less than half full on average, even when there is a high tip/bribe to be earned from including more.

1 Like