I think the concern was that because 1559 transactions are not equivalent to current transactions, there is a challenge in how to migrate all software gracefully over. One way is to temporarily support both types, but it seemed to be undefined how the two transaction types would both be supported at once.
That might be true, I’m not sure. Was just highlighting it since it was raised as another possible concern.
This seems like a large leap of logic to me that doesn’t follow. The escalator algorithm doesn’t suffer from the same miner-collusion concerns because it isn’t trying to withhold a portion of the transaction fee from miners.
I think this may be an important key point that highlights a challenge that EIP-1559 faces, along with the type of uniform-priced auction it is based on: They both try to enforce a type of second-price auction at the protocol level.
Second-price auctions typically require closed-bids, and in this case (a public blockchain) not only are the bids open, but the bids are processed by the recipient, who has the ability to add and withhold bids freely to manipulate the outcome. I think this may indicate that closed-bid auctions (like second-price auctions) are effectively impossible to enforce under these conditions, which may be why many of these threads come down to “Well then you can just use the tip parameter”, and “But isn’t that just reproducing the current structure?”.