The two discussed mitigations are mempool scanning and transaction re-signing/re-broadcasting. Mempool scanning involves regularly checking the mempool of a local node to identify any mid-cycle replacement transactions. However, this method only works if the first transaction is seen before it is replaced by the second one. Currently, most lightning nodes run on machines with a Bitcoin node on the same IP address, making it easy for an attacker to connect to the local node and perform the replacement quickly, preventing the victim from detecting it. This discoverability is also true for mining pools, where an attacker can directly target a miner's node, limiting the reach of the intermediate transaction to only miners.

The second mitigation, which involves re-signing and re-broadcasting the victim's transaction even after it has been removed, may work if the attacker is lazy and has not fully implemented their attack system. However, if the attacker has a significant portion of the network's hashrate, they can aggressively cycle through replacements, reducing the probability of the victim's transaction being confirmed. It should be noted that these mitigations are not considered effective fixes for the issue.

In a hypothetical scenario where the P2P network has slow nodes and behaves strangely, there might be some luck involved in these mitigations successfully preventing an attack. However, this is not a reliable solution. The ultimate fix for this issue would be when miners keep a history of transactions they have seen and attempt to include them in the mempool after a potential attack like this has taken place.

Please note that the above information is extracted from an email sent by Antoine Riard on 10/16/23 at 12:57 PM.