Author: Clara & Sergei
Source: https://raw.githubusercontent.com/s-tikhomirov/ln-jamming-simulator/master/unjamming-lightning.pdf
The original paper was published in 2022 and proposed a method now called " HTLC endorsement " to solve lightning channel blocking attacks.
summary
Users of decentralized financial networks encounter new forms of security breaches. Identity-based fraud prevention methods cannot be applied in such networks, which contradicts their privacy-oriented design philosophy. New mitigation strategies are needed. However, introducing new methods may hurt other useful properties of the network.
In this paper, we propose a framework for evaluating mitigation strategies in decentralized financial networks. This framework allows researchers and developers to examine and compare proposed protocol modifications across multiple dimensions, such as privacy, security, and user experience.
As an example, we analyzed a “jamming attack” in the Lightning Network, a peer-to-peer payment channel network built on the Bitcoin protocol. A jamming attack is a cheap denial-of-service attack that allows an adversary to temporarily disable some Lightning channels by flooding them with failed payments.
We propose a practical solution to blocking attacks that combines unconditionally paid fees and peer reputation. Guided by this framework, we show that our solution maintains the incentive compatibility of the protocol while curbing blocking attacks. The solution also maintains security, privacy, and user experience, and is straightforward to implement. We support our conclusions with analysis and simulations. Furthermore, our anti-blocking solution may help mitigate other problems, such as malicious channel balance detection.
1 Introduction
Decentralized blockchain protocols, such as Bitcoin, represent a new paradigm for financial networks. Their core design principles are trustless access1 and user privacy. To this end, users are identified by public keys, and a virtually unlimited number of public keys can be generated. Anyone can join such a network without formal identification. This feature makes traditional identity-based anti-fraud methods impossible to implement at the protocol level.
At the same time, decentralized financial networks are also coveted by attackers. When attacked, users and service providers will lose their funds or expose their privacy.
Footnote 1: Permissioned networks, in contrast, are run by a known set of participants. Such systems are outside the scope of this article.
In this environment, reputation and economic incentives become the main tools of mitigation strategies. The former is used to identify bad actors from honest users and selectively block them. The latter is used to impose costs for unwelcome behavior and may also compensate victims.
When proposing a protocol change, we analyze its effects on the network as a whole. New proposals must not introduce new attack surfaces, sacrifice user experience, or compromise privacy and security. Failure to recognize and work around unavoidable trade-offs can render mitigations completely useless. Also consider the difficulty of implementation.
This paper focuses on mitigation strategies for attacks on permissionless financial networks. One of our main concerns is whether a proposed solution, assuming it addresses the attack, would significantly undermine other aspects of the protocol. To avoid "throwing the baby out with the bathwater", we propose a general framework for designing and evaluating mitigation measures. As a case study, we consider mitigation strategies for channel blocking attacks in the Lightning Network (LN).
The Lightning Network is a payment network built on top of Bitcoin, designed to address the inherent transaction throughput limitations of the Bitcoin blockchain protocol. Channel blocking attacks are a long-standing [47] but unsolved DoS attack surface in the Lightning Network. They allow an attacker to cheaply and efficiently disable the victim's channel. Blocking attacks prevent users from using the core functions of the network and reduce users' forwarding fee income. The Lightning Network community has discussed many measures to mitigate channel blocking attacks [16], but none have been implemented.
Translator’s note: “【】” is the reference number.
To demonstrate the power of our framework, we use it to refine an effective solution to channel blocking that has no fundamental flaws.
Our Contribution
- We propose a general framework for evaluating attack mitigations . This framework helps ensure that the proposed changes do not significantly weaken existing protocol strengths.
- We propose a mitigation strategy for channel blocking . Our solution combines unconditional payment of fees with a local reputation system based on peers' past behavior. We evaluate our solution through the lens of the framework defined above, thus defending its design choices.
The following is organized as follows. First, we present our evaluation framework (Section 2). Then, we provide background on the Lightning Network, and channel blocking in particular (Section 3). We apply the evaluation framework to design decisions related to channel blocking mitigation (Section 4), and then present our solution to channel blocking (Section 5), which combines unconditional fees (Section 5.1) and a local reputation system (Section 5.2). We then discuss simulation results (Section 6) and review related work (Section 7). Finally, we list future work directions (Section 8) and draw conclusions (Section 9).
2 A Framework for Evaluating Mitigation Strategies
We recommend evaluating mitigation measures from the following perspectives.
Effectiveness . Mitigations should deter or prevent attacks. The adversary must pay a price, which can be monetary (paying a fee or being punished), time (needing to build up reputation before attacking), or a combination of both. Note that the attacker's motivation is not necessarily only related to money (e.g. wanting to maliciously damage the network).
Incentive compatibility . Mitigation measures should maintain the incentive compatibility of the protocol. Decentralized networks rely on the rationality of participants: following the rules should be consistent with their best interests. Payment networks should incentivize nodes to forward payments and report failures honestly.
User experience . Mitigation measures should not destroy the user experience. Changes to the interface should be intuitive and easy to explain. User experience should be evaluated from the perspective of both end users and professional service providers.
Privacy and security . Mitigations should not significantly sacrifice user privacy. Regarding security, we must ensure that proposed protocol changes do not introduce new attack surfaces. The negative effects of mitigations must be carefully weighed against their potential benefits.
Difficulty of implementation . Mitigations should be straightforward to implement. Protocol changes require a rough consensus among the community (especially developers) [46]. Proposals that are easy to implement are more likely to be adopted rather than permanently postponed.
The above framework can be used as follows. First, consider all possible categories of mitigation measures. Second, eliminate strategies that are clearly incompatible with at least one of the above criteria. Finally, compare the costs and benefits of the remaining options in the specific network context.
We would like to point out that the first two criteria (effectiveness and incentive compatibility) are hard criteria for useful solutions. The last three often require trade-offs. Sometimes, using a more centralized architecture or accumulating more user data can improve the user experience, but this will sacrifice privacy. Similarly, strategies that are simpler to implement may require users to trust some preset third parties.
Note that some of the above criteria are (at least to some extent) objectively quantifiable, while others are largely subjective. Bypassing these trade-offs depends on the specific network and attack.
3 Overview of Lightning Network and Channel Blocking
Permissionless blockchain networks face inherent scalability challenges, which is exactly the problem that layer 2 (L2) protocols aim to solve [19]. They hope to increase transaction throughput while leveraging the security guarantees of the underlying blockchain network.
The Lightning Network is a major L2 protocol built on top of Bitcoin [38]. Pairs of Lightning nodes open a payment channel by locking funds in a jointly owned funding address. They then effectuate payments by reflecting the latest allocation of funds in the channel state . Payments occur off-chain and are settled on-chain only when necessary. A penalty mechanism ensures the economic security of balance updates.
To initiate a multi-hop payment, the sender first finds a suitable path connected by channels to the receiver2. Assume that there is a node ($U_i, 0 <= i <= m $) on a path $U_0, … , U_m$. The path to the sender ($U_j, 0 <= j < i$) is called "upstream", and the path to the receiver ($U_j, i < j <= m$) is called "downstream". The peer nodes of U i on the path ($U_{i-1}$ and $U_{i+1}$) are called the upstream and downstream nodes of the node, respectively.
Each routing node , after receiving a forwarding request, either forwards the payment or lets it fail . If a forwarding node fails a transaction, it alerts the sender, who can try to bypass the failed node. The receiver, after receiving the payment, can also claim the funds or fail it. When claiming the payment from the last routing node, the receiver must reveal a secret value that allows the forwarding node to claim the funds from its upstream peer node, and so on.
Receiving nodes must also update their upstream nodes on the channel state when rejecting an incoming payment. Nodes are expected to terminate a payment only when they lack the resources (e.g., liquidity) to forward the payment. Nodes generally do not restrict the amount of liquidity an incoming payment can use3 .
A payment is said to be settled , whether it is taken or terminated. Payments that remain unsettled for a period of time are cancelled and the channel is closed .
Unresolved payments lock up some of the liquidity of every channel along the way. This liquidity cannot be used to forward other payments. Moreover, a channel can only have a certain number of pending payments at a time. This limit comes from the Bitcoin protocol rules: fraudulent channel closures with too many pending payments cannot be adjudicated on- chain5 . Therefore, we say that each channel has a limited number of payment slots . Each pending payment occupies a payment slot and a certain percentage of liquidity.
For privacy, Lightning payments use onion routing. Routing nodes know their direct peers on the path, but cannot know the original sender and the final recipient6.
Footnote 2: A payment may be split and sent along different paths [40].
Footnote 3: Valve-based flow control has recently been proposed [36].
Footnote 4: A comprehensive description of the protocol can be found, for example, in [8].
Footnote 5: A channel can only have 483 pending payments at any given time. Users may set lower limits for their channels.
Footnote 6: This assumption can be violated in timing attacks [43].
Channel blocking
Blocking is a denial of service attack on lightning channels. The attacker controls both ends of a target path, sending payments on one end and refusing to claim them on the other, thereby blocking the liquidity and payment slots of all channels on the entire path. The goal of a blocking attack may be to paralyze a group of channels (for example, channels belonging to a commercial rival) or even the entire network.
We need to distinguish between liquidity-based blocking and slot-based blocking. The former is mainly aimed at locking up the liquidity of the victim channel, while the latter is aimed at occupying all slots. In general, liquidity-based blocking is more costly. To occupy a slot, one only needs to forward a payment that exceeds the minimum size of the target node willing to forward7. Slot -based blocking can be said to be more "efficient" because no matter how large the capacity of the victim channel itself is, it only costs the same amount of money to block it.
We also need to distinguish between fast and slow blocking. In a fast blocking attack, the attacker sends a series of blocks that resolve within seconds, thereby simulating a failed honest payment. In contrast, slow blocking resolves after a long delay (on the order of hours or even days), allowing the victim to detect the attack. The boundary between the two depends on the subjective definition of the maximum resolution delay for an honest payment.
An attacker may pursue a variety of goals. We should point out that users participating in the network generally have two main goals: to send and receive payments; and to earn fees from forwarding payments. Therefore, an attacker may want to prevent users from exchanging payments, or they may want to prevent the providers of forwarding services from earning fees.
Congestion attacks are completely free. The attacker does not pay fees, as routing nodes do not charge fees for terminated payments. The only cost to the attacker is the opportunity cost of the funds locked during the attack9 , and the cost of opening the channel. Onion routing makes congestion mitigation measures more difficult to design, as the identity of the sender is unknown to routing nodes.
Footnote 7: Slot-based blocking payments must also be larger than the dust limit — the minimum amount that occupies a slot in a forwarding channel. Payments smaller than the dust limit are allowed (although their security guarantees are weaker), but they cannot be used in (slot-based) blocking attacks because they do not occupy a slot. Also, because their value is too small, they are not practical to launch blocking attacks against liquidity.
Footnote 8: Technically, an attacker could also disguise a blocking payment as a successful payment, in which case they would pay a fee. However, in the following, we will always assume that a blocking payment will terminate, rather than succeed.
Footnote 9: For further details on channel costs, see [18].
4 Design choices for congestion mitigation measures
Various congestion mitigation strategies have been proposed [16, 33]. They can be categorized as monetary-based and reputation-based. To systematically analyze the design space of solutions, we first list the possible design choices and then evaluate them based on the framework described in Section 2.
4.1 Currency Scheme
The goal of monetary schemes is to make attacks more expensive. These strategies can also compensate victims. In the context of blocking attacks, the idea of monetary schemes is to charge a fee for terminated payments on top of the existing fee ( which is only charged for successful payments ). We consider the following design choices.
- Who can receive this part of the fee? The recipient can be: a downstream node, a third party that is recognized by all parties, or simply no one (who can provably destroy this part of the fee).
- Which currency should be used to pay this part of the fee? The fee can be paid with the network's native asset (Bitcoin in the Lightning Network) or other assets. In the scheme of destroying the fee, the fee can be charged by solving the workload puzzle.
- Should this fee be paid unconditionally? The simplest fee design is one that is paid unconditionally up front (i.e. when a payment is made). An alternative is to return the prepaid fee (for termination cases) when the payment is successful. Other options can also be considered.
- How to calculate the amount of this fee? Currently, the Lightning Network fee consists of two parts: a constant basic fee, and a fee that is linearly proportional to the payment amount. More complex fee algorithms may depend on other parameters.
It is simpler to pay fees to a peer than to a third party, because introducing a third party complicates the economic incentives. The Lightning Network itself does not provide an obvious way to provably destroy funds10 , so a solution based on proof of destruction is difficult to implement. Therefore, we narrow the design space of fee payments to downstream peers.
Unconditional fees without returns are easier to implement, at least the return mechanism requires multiple value transfers.
As for the fee calculation, for simplicity we use the same structure as the existing success fee (i.e., base fee plus proportional fee). We assume that the fee amount is always positive11 (i.e., always paid to downstream peers, not upstream peers). It would be nice to have the fee amount tied to the actual payment resolution time, but we are not currently aware of any reliable way to achieve this.
As for user experience, privacy, and security, the benefits and drawbacks of the alternative designs are similar.
Footnote 10: In contrast, base-layer bitcoins can be sent to provably unspendable addresses.
Footnote 11: Bidirectional transaction fees (including fees paid to upstream nodes) are discussed in [16]. Because advertising negative transaction fees may attract unwanted flows, this proposal requires further evaluation.
4.2 Reputation Scheme
In a reputation-based strategy, nodes keep track of their trust level in other nodes. In the context of a blocking attack, reputation scores help routing nodes distinguish good peers from bad peers and either terminate payments from the latter or disconnect from them completely. When designing a reputation scheme, we have to consider the following design decisions.
- Whose reputation influences the forwarding of payments? A common design pattern in P2P networks [28] is for a routing node to consider only the reputation of its upstream peers. In addition to this pattern, the reputation of the original sender can also be attached to the payment. We call the scheme that only scores peers a local reputation scheme, and the opposite a global scheme.
- Does the reputation mechanism require consensus? Nodes can score independently, or they can try to reach a consensus on the reputation of all nodes at the network level.
- Is reputation homogeneous? Homogenized reputation scores are in the form of tokens that can be transferred between nodes. Non-homogenized reputation scores, on the other hand, are inseparable from the node that originally issued the score.
- How are they scored? One approach is to base it on the past behavior of peers. Another approach is to base it on the commitment of some scarce resource, such as proof of work or proof of ownership of Bitcoin ( certificate of stake [34]).
Schemes that attach sender reputation to payments violate the privacy goals of the Lightning Network.
Since nodes can only objectively sense the behavior of their peers, reputation scores should be local.
Due to concerns about Sybil attacks, we prefer independent ratings rather than a consensus-based reputation system.
We prefer a non-fungible solution because the secondary market for reputation tokens poses a significant challenge to the security of the design12 .
Finally, we chose to base our scoring on past behavior rather than commitment to a scarce resource. Given its failure as a bombing prevention measure [25], proof of work appears to be of little use from this perspective. In particular, the amount of work required to deter attacks is unacceptably high for honest users. We leave the evaluation of other reputation schemes based on scarce resources to future work.
Footnote 12: Previous studies have shown that it is difficult to design a secondary market for application tokens [10, 14, 51]. For example, large institutions can obtain a large number of such tokens to manipulate the market.
5 Our solution to blocking attacks
Based on the arguments in Section 4, we propose a two-pronged strategy to mitigate blocking attacks.
- Unconditional transaction fees , paid to downstream nodes, solve fast channel blocking by imposing a small cost on each payment.
- Local reputation , based on past behavior, addresses slow blocking attacks by penalizing peers that forward payments that take too long to resolve.
In Sections 5.1 and 5.2, we give more details on the unconditional fee and local reputation system. We examine these two parts of our solution through the framework proposed in Section 2 and then discuss best practices for parameter selection.
5.1 Unconditional Fees
Consider a payment path $U_0, … , U_m$ . Let $f_{i, i+1}$ denote a fee paid by $U_i$ to $U_i+1$ , where $i \in [0, m-1]$ . We denote the fee to be paid in the success case as $f^S$ and the fee to be paid unconditionally as $f^N$ . For $X \in {S, N}$ , the fee benefit of type $X$ is the difference between what $U_i$ pays and what it receives:
$$F_i^X = f_{i-1}^X - f_{i, i+1}^X$$......(1)
For routing node $U_i$, our integrated fee scheme is as follows (see Figure 1).
-Figure 1. Decision tree for routing node U i . The values on the leaves represent the total revenue -
- $U_{i-1}$ pays $f_{i-1, i}^N$ to $U_{i}$.
- $U_{i}$ decides whether to terminate or forward the payment. If $U_{i}$ terminates the payment, it will not receive any more transaction fees.
- If $U_{i}$ decides to forward, it must pay $f_{i1, i+1}^N$ to $U_{i+1}$.
- The above process continues until the payment is terminated at a certain hop or succeeds. If the payment is successful, $U_{i}$ will receive $f_{i-1, i}^S$ and pay $f_{i, i+1}^S$.
If $U_{i}$ terminates the payment (rather than forwarding it), its fee income is $f_{i-1, i}^N$. If it is forwarded but the payment is terminated downstream, it is $F_{i}^S$; if it is forwarded and the payment is successful, it is $F_i^S + F_i^N$.
Note that each payment $f$ includes not only the fees paid to the downstream peers, but also the fees paid to all future routing nodes. For example, imagine a four-node path $(U_1, U_2, U_3, U_4)$, where $U_2$ and $U_3$ charge a fixed fee of 1 satoshi per payment13. Sender $U_1$ has to pay a fee of 2 satoshis when forwarding a payment to $U_2$: $f_{1, 2} = 2 $; but $f_{2, 3} = 1$. Therefore, the fee income of the two nodes is equal to: $F^2 = f_{1, 2} - f_{2, 3} = 2 -1 = 1$, $F^3 = f_{2, 3} - f_{3, 4} = 1 - 0 = 1$. This is true whether the payment succeeds or fails.
Footnote 13: “Satoshi” is the smallest unit of Bitcoin. 1 BTC is equal to 100 million Satoshi.
Effectiveness
With unconditional fees, blocking attacks are no longer free. Moreover, the two parts of the unconditional fee (base fee and proportional fee) solve blocking attacks based on placeholders and liquidity respectively. Low-value blocking payments are meant to occupy payment slots, but now they have to pay the base fee; while proportional fees can better deter high-value blocking that aims to lock liquidity.
With a properly set fee coefficient, unconditional fees allow routing nodes to earn a similar amount of revenue from blocking as from honest payments14 , thereby compensating for the economic losses they suffer in a blocking attack. This effect can be achieved by setting the unconditional fee relatively low, because the attacker has to continue sending blocking payments to maintain the effectiveness of the attack, while honest payments usually only occupy a small proportion of channel resources. Simulations also confirm this intuition (see Section 6).
Footnote 14: The amount of fees a node earns from honest payments depends on its position in the network, its liquidity management habits (e.g., rebalancing), and other factors.
Incentive compatibility
To forward a payment, a routing node allocates a payment slot and some liquidity in one of its channels with downstream peers. These resources cannot be used for other purposes while the payment is pending. Therefore, we face an incentive compatibility challenge: a routing node can take the unconditional fee and then deliberately terminate the payment. To ensure incentive compatibility, the fee income from a successful payment must compensate the routing node for the risk in forwarding the activity.
Let $\theta$ be the probability of payment termination15 . If $U_i$ decides to forward the payment, its expected fee income is:
$$\mathbb{E}(F_i|Forward)=(1-\theta)(F_i^S + F_i^N) + \theta*F_i^N$$ ……(2)
$$=F_i^N + (1-\theta)F_i^S = (f_{i-1, i}^N + (1-\theta)F^S)$$ ……(3)
If $U_i$ absolutely terminates the payment, then the payoff is just $f_{i-1, i}^N$. To ensure that $U_i$ prefers to forward the payment, the expected payoff from forwarding the payment must be higher than the payoff from terminating immediately:
$$f_{i-1, i}^N - f_{i, i+1}^N + (1-\theta)F^S > f_{i-1, i}^N$$ ……(4)
$$(1-\theta)F^S > f_{i, i+1}^N$$......(5)
In other words, the additional expected benefit of forwarding a payment must compensate the unconditional fee that the forwarding node pays to the downstream node. Senders should also avoid using channels that continuously terminate payments, even if these channels only charge low fees: this may be a malicious strategy to target the unconditional fee and not forward payments.
Footnote 15: We use a method similar to [37] (Section 4.2).
User Experience
A key concern for user experience is that charging fees for failed payments may discourage users. Wallets can abstract away these details appropriately. In practice, the expected number of attempts per payment is low 16 , even though the termination probability $\theta$ is generally high. For a payment to succeed with probability at least $p$ in at most $K$ hops, the following conditions need to be met:
$$1 - \theta^K > p$$......(6)
This is equivalent to:
$$log(1 - p) > K log \theta$$......(7)
Because $log \theta < 0$ , so:
$$\frac{log(1 - p)}{log \theta} < K$$......(8)
- Figure 2. The expected number of attempts as a function of the required success probability p for different payment termination probabilities θ. -
The number of required attempts grows only slowly (logarithmically with the required probability of success $p$). Even assuming $\theta = 20%$, the probability of success reaches 80%, 96%, and 99% after one, two, and three attempts, respectively. We conclude that the negative impact on the user experience is minimal, since each payment requires only a few attempts, and thus the unconditional fee is low (see Figure 2).
Privacy and Security
Routing nodes should not be able to know their position in the forwarding path. Unconditional fees weaken this property: routing nodes can infer their distance to the final recipient from the fee amount and the fee policy disclosed by each node17 . This problem can be solved by having the sender allocate a portion of the payment amount as an unconditional fee for the last hop (which the recipient is expected to receive), making it look like the path extends further. The disadvantage of this approach is that high unconditional fees can lead to misaligned incentives for routing nodes. We do not expect this problem to be very serious because the unconditional fees are inherently low.
Footnote 17: From this perspective, fees charged for successful payments are less problematic, since routing nodes do not know what percentage of the payment represents fees. In contrast, unconditional fees are independent of the payment amount.
Difficulty
Unconditional fees are easy to implement. One approach is to pay them upfront. Another approach is for downstream node $U_i$ to withhold a fee $f_{i-1, i}^N$ before returning funds to $U_{i-1}$ at the end of the payment, as done in a proof-of-concept implementation [48]. Other implementation tasks include announcing additional fee policies in gossip messages and considering unconditional fees in routing decisions.
5.2 Local Reputation Scoring
Unconditional fees alone are not enough to solve blocking attacks. Therefore, we also need a reputation-based mitigation strategy. By definition, a reputation scheme consists of three parts: initialization, reputation update, and selection based on reputation score.
initialization
During the initialization phase, the node needs to set the following parameters:
- τ (seconds) — maximum resolution time to distinguish honest from dishonest payments;
- t (seconds), T (seconds), A (satoshis/second) — parameters for reputation updates (see below);
- K (integer), L (satoshi) — high-risk quota for payment slots and liquidity.
The specific values of the above parameters depend on the risk appetite of the node. For example, higher values of K and L reflect higher risk tolerance. Routing nodes should weigh the increase in revenue from honest but riskier payments (e.g., from new nodes) against the corresponding risk of blocking attacks. The values of t, T, and A may depend on the cost of opening new channels to process honest payments while existing channels remain blocked.
Update reputation score
We consider two possible values for reputation scores: high and low (more granular schemes are possible). Initially, all nodes have only low scores. If a payment is settled within τ seconds, it is considered honest . Otherwise, it is considered blocked. A peer is defined as good if it only forwards honest payments. Moreover, these payments only require a fee of A satoshis per second to be paid to the routing node. If a peer behaves well for a long enough period of time, its score is upgraded.
More specifically, reputation scores are updated like this:
- If a peer node maintains good behavior during time period t, change its score to high ;
- If good behavior cannot be maintained for t seconds within the time window T seconds, change to Low .
The reputation update algorithm based on sliding time windows can tolerate occasional errors while punishing persistent misconduct. Similar methods have been used in earlier P2P systems [13].
If peer nodes agree in advance to tolerate intentionally delayed settlement of payments18 , then such payments will not affect the reputation of the node that forwarded the payment.
Footnote 18: This is useful for some L2 protocols, such as atomic swaps [55] (e.g., submarine swaps [6]) and “prudent logging contracts” [26]. More research is needed to analyze the performance of such protocols in multi-hop environments.
Forward
A node proposing a payment can (but is not required to) mark a payment as low risk, that is, endorse it19 . Its downstream nodes ( the nodes that accept the request ) agree that the payment is low risk if and only if they verify that the endorsement comes from a peer with a high reputation. Low-risk payments can be forwarded on a best effort basis, whereas high-risk payments can only use K payment slots and a liquidity quota of L satoshis. In short, quotas apply to downstream nodes, and reputations apply to upstream nodes.
Footnote 19: This distinguishes our proposal from sender reputation-based schemes (which we have rejected among ourselves): the risk score is attached to the payment, regardless of its initial sender.
Effectiveness
An attacker with low reputation can no longer completely block a channel, because the channel will leave some resources for low-risk payments. To circumvent this countermeasure, the attacker needs to build up a reputation in advance, which requires energy and resources. Note that in order to obtain a high reputation score, a node must forward payments, paying A satoshis per second as a fee for at least t seconds.
One drawback of the reputation scheme we propose here is that it can make potentially inefficient use of channel resources. In large payments, some honest high-risk payments may be terminated due to lack of high-risk quota. Another concern is that an incomplete blocking attack, which targets only high-risk quota payment slots and liquidity, can become cheaper than a full blocking attack.
Incentive compatibility
Routing nodes should be incentivized to endorse payments to the best of their knowledge, with two possible deviations being endorsing high-risk payments and not endorsing low-risk payments. Not endorsing low-risk payments obviously reduces the node's own fee income. More interestingly, endorsing high-risk payments can increase the expected return of the endorsing node if the payment succeeds, at the risk of losing reputation in its own downstream nodes (if the payment turns out to be a block). By setting reasonable reputation system parameters, this strategy can be made unprofitable. If rebuilding reputation is very expensive, then the additional fee income will not be enough to cover the risk of incorrect endorsement.
User Experience
The user experience annoyance of this proposal is mainly for new users, who may experience higher failure rates because they start with low reputation. For idle users, this may not be a serious problem because the high risk quota of their peers is sufficient to cope with their low payment volume. Moreover, professional Lightning Network service providers may provide customers with more relaxed reputation policies.
Privacy and Security
Regardless of whether a payment is endorsed, a node will leak information about the possible source of the payment. In order to protect the privacy of the original sender, a node can choose not to endorse some low-risk payments (at the cost of losing a small amount of transaction fee income).
The security risk of the reputation mechanism is a cascading attack, which allows blocking transactions to pass through a long forwarding path, thereby reducing the reputation scores of nodes along the way. This will hurt the performance of the entire network because nodes will mistakenly terminate many low-risk payments. Although lowering the reputation score of routing nodes makes payments more likely to fail, it cannot completely block the payment flow.
The principles of cascade attacks have been studied in a variety of contexts, such as the financial industry [32], the Internet of Things [17], and virus proliferation. These papers have well established the risks based on theoretical results (e.g., [7, 11, 39]). Inspired by these studies and the properties of the Lightning Network [29], we speculate that cascade attacks are difficult to implement. Further research is needed on parameter selection and attack strategies.
Translator 's note: According to a simulation experiment by Carla Kirk-Cohen et al. in September 2024 , after applying the author's solution, the only attack that can block the channel for a long time is the one that uses the so-called "cascade attack" method here. It may be necessary to improve the reputation system to deal with it.
Difficulty
The reputation system we propose is relatively easy to implement. Additional development would include adding fields to the payment data structure to encode endorsements. Nodes would also be able to record the reputation scores of their peers in a local database.
6 Simulation
(slightly)
7 Related Work
Discussions on blocking attacks date back to 2015 [1, 47]. A summary of cutting-edge approaches can be found in [16, 33, 41].
The effects of blocking attacks, as well as improvements to these attacks and potential countermeasures, have been well studied [15, 30, 31, 35, 42, 52]. Prepayment as a countermeasure has been discussed previously [45, 22]. Related approaches include certificates of stake [34] and node-level defenses [2, 36]. Centralized global node scoring is also an option, but is rarely used in practice [5].
Attacks like “flood and loot” [20] and “mass withdrawal” [50] can blast L2 protocols by creating congestion at the base layer. Privacy attacks on the Lightning Network include balance detection [12, 21], timing attacks [43], and cross-layer deanonymization [23, 44]. As of today, no mitigation strategies have been applied.
8 Future Work
Future work includes simulating more attack scenarios and reputation-based defense strategies. More generally, the feasibility of other design choices can be considered. Considering the settlement time of payments and privacy-preserving sender reputation schemes in the fee amount are particularly interesting directions, although these ideas have unresolved theoretical and practical difficulties. In addition, the cost and efficiency of blocking attacks can be studied under different attack targets and success criteria.
An effective countermeasure might alleviate other Lightning Network issues. First, it would discourage detection attacks [21], since detection, like blocking, requires sending many intentionally failed payments. Second, our fee scheme might also be useful for incentivizing trustless watchtowers [9, 24, 29] — third-party services that defeat fraudulent channel closures on behalf of users.
9 Conclusion
In this paper, we develop an evaluation framework for attack mitigation strategies in decentralized financial networks. As a case study, we consider blocking attacks, a long-standing denial-of-service attack surface in the Lightning Network, the dominant L2 protocol on Bitcoin. After considering multiple design choices within our proposed framework, we propose an effective solution to mitigate blocking attacks by combining unconditional fees and local reputation scores based on past behavior. We demonstrate the feasibility of our proposal using simulations and analytical computations.
Acknowledgements
We thank Sergi Delgado Segura for his proof-of-concept implementation of unconditional fees. We thank Carla Kirk-Cohen, Thomas Huet, Joost Jager, Gleb Naumenko, René Pickhardt, Antoine Riard, Bastien Teinturier, and the wider Lightning developer community for insightful discussions.
References
(slightly)
