Commitment delay asymmetry [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2018-04-16T11:56:16+00:00


Summary:

The discussion revolves around the addition of a new attack vector to mitigate another attack vector in the Lightning Network. The concern is that the new attack may be easier to perform and there is no guarantee that it will eliminate the previous attack vector. In a symmetric-delay world, an attacker can trigger the lockup period immediately in the active attack. However, the risk is that the other side may decide not to close the channel unilaterally anyway. The two attacks in the symmetric case do not seem any different from one another. In both cases, an attacker forces a unilateral close by becoming unresponsive and forcing the other side to eventually broadcast the commitment. The difference is that in the second case, an attacker forces a unilateral close by broadcasting himself, which is a weaker attack.To address the concern of channel closure asymmetry, Daniel suggests scaling the delay of the other side's closure based on the balance of the channel. The delay on the remote output would scale from zero delay up to the same delay as the side unilaterally closing the channel. This way, the punishment delivered is no greater than the time-value lost by the initiator of the unilateral close. However, an attacker should always prefer to become unresponsive rather than broadcast the commitment themselves.In terms of setting up a channel, the commitment delays do not need to be the same in both commitment transactions. A better rule might be to set the delay as min(to_remote_delay, to_local_delay * to_local_value / to_remote_value), so the punishment duration is reduced if the attacker broadcasts a commitment transaction in which the balance of funds is skewed towards the victim's end of the channel. However, the writer argues that an attacker should always prefer to become unresponsive rather than broadcast the commitment themselves.In the context of their branch, the writer discusses the delay involved and how they can get money immediately without it being revoked. They mention receiving 1.0BTC and 0.99BTC worth of Daniel products. The writer clarifies that the side unilaterally closing the channel would always have to wait for the full delay to allow time for revoke transactions to be broadcast. However, they suggest applying a delay on the remote output based on the balance distribution to avoid misbehaving nodes from unilaterally closing channels where they have little or no balance, thereby locking up the funds of the remote node at virtually no cost to itself.ZmnSCPxj discusses two possible attack scenarios in the world of symmetric and asymmetric delays. In a symmetric delay scenario, he can use either passive or active attacks to force most funds into the other side, resulting in lockups for both parties. In an asymmetric delay scenario, he can only use a passive attack to force most funds into the other side, resulting in lockup for the other party only. ZmnSCPxj argues that adding a new attack vector to mitigate another attack vector is not a good trade-off as it creates a new attack that is easier to perform than the current attack.The effectiveness of using asymmetric delays to prevent denial-of-service (DOS) attacks in the Lightning Network has been questioned. The delay only affects the honest node and not the attacker who can still unbalance the channel in their favor, reducing their funds to a reserve balance. Even with the delay, the attacker can refuse to participate in a mutual close, forcing the channel to be closed on-chain. This is seen as an active attack that is just as bad as the previously mentioned DOS attack. It's been suggested that symmetrical delay commitment transactions could create cheaper disruptions, particularly if a channel is unbalanced in favor of one party. However, this attack is more passive than the one under a symmetrical delay commitment transaction scheme.In a conversation about the Lightning Network, Daniel proposes a solution to address the concern of channel closure asymmetry. He suggests scaling the delay of the other side's closure based on the balance of the channel. If the side unilaterally closing the channel has zero balance, the other side gets no delay and symmetry as measured by (coins locked) * (duration of lock) equals zero on both sides. When the side closing the channel has at least 50% of the balance, both sides must wait the full delay. However, he notes that an attacker could still perform a costless attack in the situation where funding a new channel is required.The discussion revolves around the potential for denial-of-service (DoS) attacks on the Lightning Network and the use of symmetric or asymmetric delays in commitment transactions as a mitigation strategy. Jimpo argues that an attacker could achieve the same outcome with asymmetric delays by refusing to participate in a mutual close, forcing the other party to close on-chain. This results in wasting the time-value of the other party's money in the channel, but the attacker loses access to some funds for some time too. ZmnSCPxj agrees that this is a concern and proposes delaying the outputs of the holding commitment transaction instead of making it symmetrical.


Updated on: 2023-07-31T19:59:51.288590+00:00