The sender clarifies that no such attack has been observed on the mainnet. However, they mention conducting a demo attack in restricted dev circles to experiment with different scenarios. The risk of exposure is highlighted if an attacker targets channels with high capacity and loose channel policies.

To observe the existence of such an attack, the recipient is advised to look at their mempool logs and monitor the amount of HTLC output being systematically conflicted out with the sequence of HTLC-timeout, HTLC-preimage, HTLC-timeout, and so on. It is emphasized that this attack is not akin to a pinning attack and can happen without network mempool congestion.

The email suggests a strategy for the attacker to control two neighboring nodes to target the victim. By cycling the attack on the tail side and delaying the confirmation of the HTLC-timeout covenant, the peer at the front of the victim's incoming link will force-close the channel and claim their timeout-path, canceling back the initial HTLC amount to the attacker's initial node. This behavior is deemed worthy of testing as it creates a race between the victim and the attacker on the tail side, making the attack even more costly.

The email mentions that Local-mempool preimage monitoring has been implemented by Eclair and LND as a mitigation against old school pinning attacks and replacement cycling attacks. However, it is noted that Core-Lightning or LDK have not implemented this mechanism.

A proposed defensive fee mitigation strategy is discussed, which involves aggressively fee-bumping the HTLC-output and grabbing the preimage while claiming it on the incoming. This strategy is only feasible with anchor channels where fees can be added to the HTLC-covenant. By cycling this process 144 times, the attacker would incur heavy losses trying to steal the HTLC.

The email also highlights the lack of a way at the specification level to negotiate the cap on the total value of outbound HTLC in-flight. This can lead to losses for the attacker when trying to steal small HTLCs.

Overall, the email provides insights into the potential risks and strategies related to attacks on Lightning Network channels with high capacity and loose channel policies.