Author: Jaleel, BlockBeats

Editor: Jack, BlockBeats

In an email dated October 16, 2023, Antoine Riard, a Bitcoin security researcher, delved into the risk of fund loss faced by Lightning Network channels, which is mainly caused by issues with the transaction pool. He specifically mentioned a type of transaction relay interference attack that affects Lightning Network channels, which is entirely possible in practice, even without network transaction pool congestion.

In order to deal with these attacks, several major Lightning Network implementations have designed, implemented, and deployed corresponding mitigation measures in the past few months. Riard also listed the version numbers of these major implementations: LDK: v0.0.118 - CVE-2023-40231; Eclair: v0.9.0 - CVE-2023-40232; LND: v.0.17.0-beta - CVE-2023-40233; Core-Lightning: v.23.08.01 - CVE-2023-40234.

Riard emphasized that Pinning attacks have been considered as practical attack vectors for many years, and now, the Replace-by-Fee Cycle Attack seems to provide attackers with a new means of attack.

Meanwhile, Riard stated that he will stop participating in the development of the Lightning Network from now on, as this new replacement loop attack will put the Lightning Network in a very dangerous situation.

闪电替换循环攻击如何工作？

"Lightning Swap Loop Attack" works by exploiting a vulnerability in the Lightning Network protocol.

There are many discussions about this new discovered vulnerability in the email list. Before discussing how the Lightning Replacement Loop attack works, we first need to know that the HTLC (Hash/Time-Locked Contract) creates a secure payment path from the sender to the receiver as a conditional payment tool. This path either completes the payment immediately by the receiver providing the pre-image of a hash, or the sender can retrieve the funds if it is not completed within a certain time.

The developer of BitfeedLive and mempool, mononaut (@mononautical), has created an introductory illustration here:

The core of the Lightning Network's substitution loop attack is that, assuming Bob is paying Carol through the Lightning Network via Alice, Bob has two pending HTLCs: one from Alice and one to Carol.

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a valid text to translate.

But what Bob doesn't know is that Alice and Carol are colluding to steal his money. When Carol fails to provide the original payment within the specified time, Bob attempts to time out on-chain and reclaim his funds.

At this point, Alice and Carol colluded to prepare for the attack by broadcasting the chain of two transactions, and prepared a series of low-cost transactions disguised as ordinary transactions unrelated to the Lightning Network. These transactions are called "parent loops" and "child loops".

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a valid text to translate.

When Bob's timeout transaction appears in the memory pool, the attacker immediately publishes a transaction that uses Carol's hash preimage and references the "loop parent" transaction. Because the new transaction has a higher fee rate, it replaces Bob's timeout transaction in the memory pool.

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a valid text to translate.

If the attacker continues to operate in this way, they will prevent Bob from re-publishing his timed-out transaction every time he tries. If the attacker succeeds for a long enough period of time, Alice can use another time lock on the channel between her and Bob to recover the funds.

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a valid text to translate.

Replaceable Loop Attack: Difficult to Implement and Prevent

In the face of the substitution cycle attack problem in the Bitcoin Lightning Network, Tether's CTO Paolo Ardoino has also expressed his concern. He mentioned that Bitfinex has been operating three main Lightning Network nodes since 2019, which means that this issue has also attracted the attention of other major companies.

Although Bitcoin developer Riard has indicated that he may withdraw from the development of the Lightning Network due to perceived risks, he also specifically pointed out that modifications to the Bitcoin network may be necessary to address this new attack vector.

However, in fact, this type of attack is highly complex and not easy to implement.

The founder of SlowMist, Yu Xian, shares a similar view. He pointed out on social media that in order to successfully carry out this attack, the attacker needs to meet multiple conditions, such as opening two channels on the victim and ensuring that the victim does not discover the HTLC pre-image transaction. To address this threat, Yu Xian suggests that project parties establish channels with reputable parties to reduce risk.

Although implementing such attacks is very complex, it is quite difficult for us as users to completely avoid them, even if we take some measures.

On this issue, mononaut pointed out that Bob can actively monitor his transaction pool to promptly detect HTLC timeouts. However, skilled attackers can still bypass these defenses. To truly fix this issue, we may need to make deeper adjustments. We can consider redesigning the HTLC protocol, modifying propagation strategies, or introducing new operations to address this issue.

From Sandwich Attacks to Loop Replacement

Obviously, the technique of flash loan attacks is similar to the MEV sandwich attacks on Ethereum, both of which use front-running to siphon off target funds. However, research on Ethereum's MEV sandwich attacks has not been well developed in recent years.

Recently, the Ethereum Foundation was attacked by a MEV Bot during the sale of 1700 ETH through Uniswap V3, resulting in a loss of $9101. The MEV Bot profited approximately $4060.

DeFi expert CHRIS POWERS pointed out in a recent article that since the launch of MEV-Geth by Flashbots aimed at "effectively addressing the MEV problem", there have been significant changes in the past three years. Ethereum has witnessed market ups and downs, and successfully moved towards a new stage of Proof of Stake, which is a major milestone in its technological progress.

However, the competition for on-chain economic resources has become more intense. Despite our significant efforts, the issue of MEV still exists.

There are many potential solutions to the challenge of MEV in the encryption industry. However, some people mistakenly believe that certain methods, such as fair ordering, can completely solve the problem. From the design stage, we should consider how to deal with MEV. Although many developers are working hard to reduce the impact of MEV, they also need to recognize that completely avoiding losses is not realistic.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia