I might be missing the point here, but how can an attacker delay the finalization of the channel? For any update the attacker may drop we have a response that is not encumbered by a timelock or CSV, thus all the transactions can end up in a single block. I always thought of it as this: attacker publishes an old update, the victim takes its latest update, creates two versions: a) bound to the funding and b) bound to the update the attacker broadcast.
We have several outcomes:
- the attacker succeeds in confirming its old update, in which case we have already submitted the response, and it might have been confirmed along with the first, i.e., the attacker just lost some funds, but did not succeed in claiming or delaying anything, since our own transactions were just as valid before as after the attacker published them.
- Our latest update is confirmed, the attacker doesn’t lose anything, but he also doesn’t gain anything.
This game can be iterated (unless the attacker can fill the block on its own he doesn’t have an advantage) and we just create and broadcast a matching response to anything the attacker does.
A variant of this that I could see is if a miner and the attacker collude to attack silently, not giving the victim time to response, forcing them into the next block, but unless the attacker has a majority and the timeouts are chosen correctly, the attacker cannot censor indefinitely. It’s also worth noting that in this case no system using timelocks or CSV can be safe anyway.