This is correct, and I hadn't given enough thought to this problem prior to posting.
Now that I've given it more thought, I think it can be significantly alleviated by making collection from the pool span a longer period, on the time scale of years. Relative hashrate is likely to change over these period, so it may not be the best plan to publish excessively large blocks hoping to reclaim the fee (and publishing typical-sized blocks does not give big miners an advantage). Also, with a different function you can change the balance between the marginal and total penalty so that the actual penalty is small, nullifying the effect (it will require the cap to be a bit harder, but still more elastic than what we have now).
I agree that this calls for more analysis.
A longer time period over which the reward is given doesn't help, as the larger nodes or entities will still get a larger ratio of the rolling over fees, by definition.
Actually, making the rollover fees only extend over a couple of blocks would more likely mitigate the problem, but if you roll over the fee for about 3 blocks or so, then it might be worth it for a miner to hold blocks and release 2 at a time, depending on fee-over-time. This, in turn, might exacerbate the selfish miner exploit
1. The natural monopoly condition that already exists in Bitcoin
2 seems to be exacerbated either way.
Getting around this would be tricky, if it's possible.
1http://fc14.ifca.ai/papers/fc14_submission_82.pdf2https://bitcointalk.org/index.php?topic=176684.msg9375042#msg9375042An examination of the prior art is warranted.
Pointing to Monero as an examination of prior art is asking a bit much. Are you expecting us to dig through the Monero source code? How do they get around the problem?
This is not very helpful;
The Basics
A special type of transaction included in each block, which contains a small amount of monero sent to the miner as a reward for their mining work.
https://getmonero.org/knowledge-base/moneropedia/coinbase