Priority Fees are not required, have no minimum, and are not fixed. Look at any hot account in any block, and you will see a range of PFs from zero to some maximum value. There is no such thing as a canonical PF value for any account in any block. When you say someone might offer 75%, that means 75% of what? What does this hypothetical side deal look like?
For example, I never need to pay the max PF for inclusion. If I simply pay the recent median PF, my TX will be included virtually 100% of the time. I don’t need to make 75% side deals (whatever that means) to land TXs. I’m not convinced that potential side deals are a big problem (Jito addresses the need to cut a side deal in the first place). On the other hand, the side effects could be worse…
To use PFs, you must first know the prevailing PFs for the writable accounts. Many apps estimate fees using the getRecentPrioritizationFees (gRPF) RPC method or other APIs. Reading recent PFs as input into setting PFs for the next TX creates a feedback loop that can be abused.
This proposal allows a validator to cheaply push PFs higher for hot accounts and keep 100% of the increase when senders raise their PFs to adjust the higher values. Other senders then react to the new higher values by raising their PFs, and a vicious cycle begins. (We’ve already seen the vicious cycle play out when network congestion was bad recently. It happened before and will happen again). Manipulation becomes EV+ for all validators because of the feedback loop. There is a mass incentive to cheat.
Throw in other incentives, and things get spicy. For example, can I influence ORE mining by paying ridiculously high PFs for my mining TXs in my leader slots? It will be effectively free for me to try. YOLO
The proposal allows validators to manipulate PFs without bounds. I’m opposed.