Author: Antoine Riard 2020-09-10 16:27:37
Published on: 2020-09-10T16:27:37+00:00
The recent anchor output spec update related to the new usage of SIGHASH_SINGLE for HTLC transactions may have introduced a potential vulnerability that is harmful to funds' safety. This vulnerability combined with the currently deployed mechanism of `update_fee` could be exploited to partially escape the penalty. Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty, which allows non-cooperative spending of its HTLC outputs on its commitment transactions. By increasing the feerate using `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. Alice gains 125600 sats in an example given in the post by exploiting the vulnerability. However, there are limitations to the attacker's success. Post-anchor HTLC outputs are CSV'ed by 1, which means in theory, an honest party can punish this output before the malicious spend them with the revoked HTLC txn. Channel policies could be tighter to countermeasure the vulnerability, like bounded further down `max_accepted_htlcs` or restraining acceptance of `update_fee`. Justice transactions can adopt a scorched earth approach binding their feerate to the max to increase odds of winning the feerate race and thus deter attackers. Patching current anchor spec to remove `feerate_per_kw` appliance on 2nd-stage transactions could also be a workable option.
Updated on: 2023-06-03T02:06:00.345634+00:00