There are concerns that this proposal may not fully prevent adversarial techniques such as replacement cycling, which could be exploited by a malicious forwarding node. A scenario was presented to illustrate this issue, involving three participants: Alice, Bob, and Caroll, who share lightning channels.

In the example, Alice sends 1 BTC to Caroll through Bob. The HTLC expires at block 100 on the Bob-Caroll link. Ideally, Caroll should not be able to claim the htlc-preimage spend on this link after block 100. However, if Bob, acting as the routing node, delays the process deliberately, he could potentially exploit the system. When Caroll releases the preimage to Bob off-chain, Bob refrains from sending his signature for the updated channel state. If Caroll tries to claim the inbound HTLC output on-chain before block 100, Bob can interfere with her transaction's inclusion in the blockchain through "replace-by-fee" tactics, effectively preventing her from claiming the payment.

As block 100 arrives without Caroll's successful claim due to Bob's interference, she loses the ability to claim the payment sent by Alice. Bob then exploits both the htlc-refund path on the Bob-Caroll link and the htlc-preimage path on the Alice-Bob link, profiting by 1 BTC. The risk is heightened when considering that Caroll might use a mobile client, making it easier for Bob to attribute the failure of the signature exchange to an alleged error on her part.

Given this advanced scenario, there is skepticism about whether the OP_Expire proposal can resolve all potential adversarial replacement cycling situations within the Lightning Network. This concern underlines the necessity for further examination and possible refinement of the OP_Expire mechanism to ensure it can withstand such tactics and provide robust protection against these forms of attack.