Potential sabotage scenarios

[AutonomousSystems]

Assuming i'm correct in my assumptions below (my apologies if i'm not), I'd like to know how these threats could be mitigated (if possible).

I'm assuming a scheduled transaction can be generated for any time in the (distant) future. There are multiple timenodes active with different settings which are unknown to the rest of the timenodes (below here called "TNs"). The malicious actor (called "MA") as mentioned below is calculated (potential benefit outweighs the gas+txs costs) but if there is no economic gain or loss will not shy away from disruption for its own sick pleasure.

Scenario 1:
Some but not all TNs have any amount of ether, have claiming enabled but for whatever reason have their economic strategy parameters set to default values. An MA with some ether (and DAY) to spare comes along and schedules a bunch of txs for (for example) 3 months from now with very small tx values but with fairly large demanded deposit amounts from the TN that puts the TNs at or near zero ether for the coming 3 months so they can't claim any other tx in the mean time. The MA has thus put a bunch of TNs out of business, seizes the opportunity and becomes a TN itself. He/she could try to repeat this when it sees that the other malconfigured TNs refunded themselves with ether.
--edit: now i think about it, this could be mitigated by enforcing TN deposits to be equal to or lower than the tx value.

Scenario 2:
Some but not all TNs have a little bit of ether (as is recommended by CL), have claiming enabled and correctly configured their economic strategy so the 'large deposits for distant future'-problem from scenario 1 can't affect them. An MA comes along and schedules 10000 txs for months from now with very low tx values and low deposits, but cumulatively these deposits (and perhaps the gas alone even) exceed the TNs's ether balance (or triggers the min. balance setting) and MA could potentially put all TNs out of business which were online around the time of scheduling.

A combination of above 'tactics' could potentially frustrate the timenode network to a large degree i think.

"On a long enough timeline, if it can happen it probably will", someone said once.
If you estimate this as real, maybe there should be a maximum future scheduling time? Perhaps some technical solution is possible and implementable for the Chronos protocol?

[lsaether]

I think the quick and dirty solution would be to add a parameter for maxFutureDelta dictating how long in the future a transaction is scheduled would that TN be willing to claim. Then set the default to the same as the default claim window settings so ~1 hour before execution.

Actually now that I think about it, this is how the TN currently works anyway. Since we watch for new transactions via the current bucket (the one hour block for when the executionWindow starts) and the next bucket. The TN only cares about transaction requests which will happen max 2 hours in the future. Since as I mentioned before, the default claim window begins 1 hour before execution this will work fine in most cases.

The attacks you describe only begin to happen if someone

1. modifies our code for the TN and are not aware of the risks
2. writes their own TN client and are not aware of the risks

Otherwise if someone tries to set the claim window really far in the future, it just won't get claimed by the TimeNode (running the timenode-core software).