SIGHASH_SINGLE + update_fee Considered Harmful

Summary:

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 change allows a single-party to bump the feerate of 2nd-stage HTLC transactions without counterparty cooperation, which could make HTLC funds safer. However, 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. This means that in every state, there should be no incentive to perform the attack as described, as the cheating party will gain at most the channel reserve, but at the same time lose its channel reserve. Since this makes small channels unusable at high fee rates, we also clamp the maximum update_fee we'll send at 10 sat/b.Completely adhering to the bring-your-own-fee model for HTLC-txn sounds better than current implementation as it splits more fairly fees burden between channel participants. 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. In lnd today, anchors are still behind a build flag, but they plan to enable it by default for their upcoming 0.12 release. The blockers on their end were to add support for towers, and add basic deadline aware bumping, both of which are currently on track. They'll now also look into setting clamps on the receiver end to just not accept unreasonable values for the fee rate of a commitment, as this ends up eating into the true HTLC values for both sides.The Lightning Network has a vulnerability that could allow attackers to bypass penalties. By inflating fees committed on HTLC input/output pairs, they can redirect the inflated fee to a single-controlled output attached to these malleable pairs. This would not be punishable by an honest party in case of revoked state broadcast and enable the attacker to partially escape the penalty. The attacker could gain a significant amount of money by bypassing the revocation punishment, even if channel policies are in place.There are some limitations to this attack, such as post-anchor HTLC outputs being CSV'ed by 1. Also, other limitations are the per-implementation channel policy `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and acceptance bound of `update_fee`. A workable option would be to patch current anchor spec to remove `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing a minimal relay fee.Overall, the chance of attack success sounds high, and countermeasures must be taken. Tighter channel policies could be implemented, or justice transactions could adopt a scorched earth approach binding their feerate to the max to increase odds of winning the feerate race and thus deter attackers. However, this could introduce a griefing attack vector, allowing the counterparty to burn more of the lawful balance in fees than you'll punish its revoked balance. Further countermeasures may also be necessary.

Updated on: 2023-06-03T02:13:47.316687+00:00