Thanks for the feedback
I should clarify - the congestion oracle does not rely on assumptions about which transactions miners choose to include (at least in the way I think you are saying); otherwise, we would have exactly the issue you describe, where miners could attack it super easily.
Instead, users prove to the oracle the congestion of recent blocks, by providing a block header from a recent block, confirming it is a recent block, then parsing the RLP to get the gasLimit and the gasUsed. (Note: the oracle I linked is just the bare-bones parsing bit of what is necessary to make it legit.)
If, as you describe, miners choose to always mine the Oracle, then the oracle will know if the network is congested; if miners choose to not mine the oracle (or there are no tx to the oracle), we assume it’s due to network congestion and stretch timelocks accordingly. The benefit here is that we don’t have to submit any (high fee) transactions during a congested period.
Miners could choose to censor all transactions to oracle as a sort of nuisance attack, but, in this case, we have much bigger worries; they would just choose to censor all challenges going to the state channels in the first place.
There is another, different issue with miners influencing the oracle though; they can simulate chain congestion at almost no cost (small cost is the increased risk of uncled blocks). Essentially, they can insert a bunch of fake transactions into their own blocks, convincing the oracle that the network is congested (and thus making the elastic timelocks strech when they really shouldn’t). This is probably a more reasonable and effective nusiance attack than the one described above, as it does not require a 51% majority to occur.
This can be mitigated to some degree with fee burning, but that’s a protocol level change