The deployed mitigations are not expected to fix the issue, but rather serve as a PR statement. Two mitigations are mentioned - mempool scanning and transaction re-signing/re-broadcasting.

Mempool scanning involves regularly checking the mempool of a local node to catch the replacement cycle mid-cycle. However, it only works if the first transaction is seen before the second transaction replaces it. 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 seeing the replacement. This discoverability is also true for mining pools, where an attacker can target a miner's node directly, limiting the reach of the intermediate transaction to only miners.

The second mitigation, which involves re-signing and re-broadcasting the victim's transaction, may work if the attacker is lazy and has not completed their attack system. However, if the attacker has a large majority of the hashrate, they can aggressively and arbitrarily reduce the probability of the victim's transaction getting confirmed.

The above discussion assumes ideal conditions in a P2P network, but in reality, there are slow nodes and strange behavior. It is possible that these mitigations might coincidentally prevent an attack due to delays or other factors. However, these mitigations are not considered a material "fix" for the issue. The only real fix would be for miners to keep a history of transactions they've seen and try them again after they may enter the mempool due to an attack like this.

The email was sent by Antoine Riard on 10/16/23 at 12:57 PM.