Thinking out loud here: This point stood out to me,
The attacker earns indexing rewards on the subgraph up until indexing rewards are disabled on the subgraph. Even though allocations are measured in epochs, indexing rewards accumulate continuously on a per block basis. Thus the revenue from an attack is determined by the number of blocks until a Subgraph Oracle detects the unavailable subgraph and disables indexing rewards.
Has changing the per-block rate to a per-epoch rate been considered? Why or why not is that a possible solution?
Secondly.
I also am struggling to see the direct tie in to lowering the curation tax rate. While I have looked through the maths, and understand the point that is being made, I still don’t see how it ties back directly to a “need” to lower the curation tax rate. You mentioned how this attack vector was one constraint from holding back the lowering of it, but that implies that it should be lowered.
As you wrote in the post “in instances where the subgraph needs to be upgraded multiple times due to bugs in the subgraph or due to the subgraph being under active development.”. In my mental model of a role of a Curator, these two things are paramountly their “responsibility” (for lack of a better term). They should be curating which subgraphs do/do not have bugs, and are suitable for production use (versus needing frequent updates).
I may be missing some context, or perhaps something isn’t “clicking” for me as of yet, and I would love to be pointed in that direction.