3. I intuitively expect some flaw around the variable control over fees collected per unit of PoW expended, i.e. control over difficulty. But I am too sleepy to work through this part of the paper right now.
Okay so this design issue is explained in
Automatic Drain Rate Adjustment of section 2.2.1 on page 12.
Please check my logic, because afaics that section doesn't correctly conceptualize the flaw and potential for attack.
In Bitcoin, relatively small discrepancies between miners' clocks as seen in timestamps w.r.t. to forming consensus on one chain and over lengthy 600 blocks readjustment windows is not equivalent to the case where difficulty is adjusted separately for each partial order branch of the DAG wherein hashrate can be volatile because it can be moved between branches at will; and thus it is necessary to adjust the difficulty much more frequently over shorter windows.
If the readjustment window is too long, then the high hashrate attacker can stall a branch for a long-time by throwing high hashrate at it until the difficulty adjusts then leave to another branch. Whereas if the readjustment window is short, then attacker can use timestamp manipulation to manipulate the system as well as rapidly undulating difficulty levels for different branches.
I expect Nash equilibrium failures (i.e. conflicting strategies) around the lack of consistency of difficulty levels between branches that need to converge.
As noted in
Disruption and DoS of section 4 on page 21, transaction spam is handled heuristically and is orthogonal to the need for difficulty adjustment.
Afaics, difficulty adjustments and a DAG seem fundamentally incompatible. Afair Iota doesn't need to adjust difficulty because the proof-of-work isn't rewarded.