Author: Johan Torås Halseth 2020-09-11 08:15:30
Published on: 2020-09-11T08:15:30+00:00
A potential vulnerability has been identified in the recent anchor output spec update related to the new usage of SIGHASH_SINGLE for HTLC transactions. This new malleability combined with the currently deployed mechanism of `update_fee` is likely harmful for funds safety.Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus it can spend non-cooperatively its HTLC outputs on its commitment transactions.The negotiated feerate (`feerate_per_kw`) is used by channel participants to compute effective fees which have to be deduced either from the funder balance output for commitment transactions or from HTLC output value for HTLC transactions. By increasing the feerate thanks to `update_fee`, a malicious party can inflate fees committed on HTLC input/output pairs and redirect this inflated fee to a single-controlled output attached to these malleable pairs.One limitation of attack success is that post-anchor HTLC outputs are CSV'ed by 1, which means in order to successfully steal funds, attackers must wait for the CSV to expire before spending the funds. Johan suggests that phasing out update_fee all along and only accepting the minimum relay fee (zero fee if/when package relay is a reality) should mitigate this attack completely. Olaoluwa Osuntokun suggests an even simpler mitigation is just for the non-initiator to _reject_ update_fee proposals that are "unreasonable".In the mid-term, implementations can start to phase out usage of update_fee by setting a minimal commitment fee when the channel is first opened, then relying on CPFP to bump up the commitment and any HTLCs if needed.From the perspective of channel safety, and variations of attacks like "flood & loot", it's absolutely critical that nodes are able to update the fees on their second-level HTLC transactions. As this is where the real danger lies: if nodes aren't able to get 2nd level HTLCs in the chain in time, then the incoming HTLC expiry will expire, creating a race condition across both commitments which can potentially cascade.The Lightning Network has a vulnerability where a malicious party can attach a branch of descendants to its anchor output, allowing only one more mempool victim's transaction on the revoked commitment. The victim must spend all outputs at once or they will obstruct each other at mempool acceptance. Other limitations include per-implementation channel policies such as max_accepted_htlcs, max_htlc_value_in_flight, channel_reserve, and acceptance bound of update_fee.After the revoked commitment transaction is confirmed, both attacker and victim are in a feerate race to confirm either a justice transaction or a malicious HTLC-timeout. As fee estimator logic of the victim's implementation is public knowledge, an attacker can know the range of the first fee bid and override it by a bit to confirm it before the victim RBF at the next block. Currently, not all implementations have RBF of justice transactions.If the anchor output is deployed, given how LN implementations are managing fees/rebroadcast of onchain transactions, the chance of attack success sounds high in the author's opinion. Countermeasures that could be taken include tighter channel policies or patching the current anchor specification to remove feerate_per_kw appliance on 2nd-stage transactions and committing only a minimal relay fee.However, some countermeasures, such as adopting a scorched earth approach with Justice transactions, may introduce a griefing attack vector where the counterparty burns more of the lawful balance in fees than the victim punishes its revoked balance.
Updated on: 2023-06-03T02:11:54.340016+00:00