📅 Original date posted:2020-09-10
📝 Original message:
Hi Antoine,
Great findings!
I think an even simpler mitigation is just for the non-initiator to _reject_
update_fee proposals that are "unreasonable". The non-initiator can run a
"fee leak calculation" to compute the worst-case leakage of fees in the
revocation case. This can be done to day without any significant updates to
implementations, and some implementations may already be doing this.
One issue is that we don't have a way to do a "soft reject" of an update_fee
as is. However, depending on the implementations, it may be possible to just
reconnect and issue a co-op close if there're no HTLCs on the commitment
transaction.
As you mentioned by setting proper values for max allowed htlcs, max in
flight, reserve, etc, nodes are able to quantify this fee leak risk ahead of
time, and set reasonable parameters based on their security model. One issue
is that these values are set in stone rn when the channel is opened, but
future iterations of dynamic commitments may allow us to update them on the
fly.
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. This
discovery might very well hasten the demise of update_fee in the protocol
all together as well. I don't think we need to depend entirely on a
theoretical package relay Bitcoin p2p upgrade assuming implementations are
willing to make an assumption that say 20 sat/byte or w/e has a good chance
of widespread propagation into mempools.
>From the perspective of channel safety, and variations of attacks like
"flood & loot", imo 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.
In lnd today, anchors is still behind a build flag, but we plan to enable
it by default for our upcoming 0.12 release. The blockers on our end were to
add support for towers, and add basic deadline aware bumping, both of which
are currently on track. We'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.
-- Laolu
On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi,
>
> In this post, I would like to expose a potential vulnerability introduced
> by 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.
>
> This has been previously shared with deployed implementations devs, as
> anchor channels are flagged as experimental it's better to discuss and
> solve this publicly. That said, if you're currently running experimental
> anchor channels with non-trusted parties on mainnet, you might prefer to
> close them.
>
> # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)
>
> First, let's get started by a quick reminder of the data set committed by
> signature digest algorithm of Segwit transactions (BIP 143):
> * nVersion
> * hashPrevouts
> * hashSequence
> * outpoint
> * scriptCode of the input
> * value of the output spent by this input
> * nSequence of the input
> * hashOutputs
> * nLocktime
> * sighash type of the signature
>
> 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. I.e when Alice broadcasts her commitment transaction, every
> Bob's signatures on Alice's HTLC-Success/Timeout transactions are now
> flagging the new sighash type.
>
> Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs`
> (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the
> output scriptpubkey/amount at the same index that
> the spending input. Alice is free to attach additional inputs/outputs to
> her HTLC transaction. This change is aiming to let a single-party bump the
> feerate of 2nd-stage HTLC transactions in case of mempool-congestion,
> without counterparty cooperation and thus make HTLC funds safer.
>
> The attached outputs are _not_ encumbered by a revokeable redeemscript for
> a potential punishment.
>
> That said, anchor ouput spec didn't change disable the current fee
> mechanism already covering HTLC transactions. Pre/post-anchor channels are
> negotiating a feerate through `update_fee` exchange, initiated by the
> channel funder. This `update_fee` can be rejected by the receiver if it's
> deemed unreasonable compared to your local fee estimator view, but as of
> today implementations are pretty liberal in their acceptance, admitting a
> divergence from a scale of 1 to no-bound at all.
>
> This 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.
>
> # The Vulnerability : a Penalty Escape Vector
>
> 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. This won't be punishable by an honest party in case of revoked state
> broadcast and thus enable to partially escape the penalty.
>
> As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw`
> is 10000 sats.
>
> At state N, Alice balance is all on her side. She announces 10 outgoing
> HTLCs of value 7000 sats.
>
> As Commitment tx weight with 10 outputs is 2844 (post-anchor), the
> absolute fee committed is 28440 sats.
>
> As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is
> of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat.
> This absolute fee aims to pay the miner fee in case Alice needs to timeout
> HTLC onchain.
>
> Her remaining balance is 1560 sat, above both dust_limit_satoshi and the
> channel reserve as constrained by Bob (likely 1%).
>
> Alice waits for HTLCs to expire and advances state to N+1. Then she
> empties her balance minus reserve by sending a HTLC relayed by Bob either
> to a colluding channel on the rest of network or back to an onchain address
> thanks to a swap service.
>
> At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost
> all of the absolute fee to a new P2WPKH output only controlled by her. She
> broadcasts the revoked commitment tx N and burns 28440 sats in commitment
> fee.
>
> Her balance of 1560 sats is punished by Bob's justice transaction.
>
> After confirmation and thus maturing of the CSV of 1 on her HTLC output
> Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to
> pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.
>
> Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560
> (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs
> fees) - 340*10 (HTLCs output) = 125600 sats.
>
> Alice's gain is superior at channel value as it has been partially
> double-spend by bypassing the revocation punishment.
>
> # Limitations of Attacker Success
>
> A first limitation of attack success which can be point of is the fact
> that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a
> honest party can punish this output before the malicious spend them with
> the revoked HTLC txn. In practice a malicious party can attach a branch of
> descendants to its anchor output and that way only allowing one more
> mempool victim's transaction on the revoked commitment. The victim must
> spend all outputs at once or otherwise they're going to obstrucate each
> other at mempool acceptance.
>
> Secondly, 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 quick look at default policies, even if
> they vary between deploy implementations, let it think there is room to
> escape a substantial part of channel value.
>
> Lastly, 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 a public piece of knowledge, it shouldn't be
> hard for the attacker to know the range of the first fee bid and override
> it by a bit to confirm it before the victim RBF at next block. Currently,
> not all implementations have RBF of justice transactions.
>
> As of today, if anchor output is deployed and given how LN implementations
> are managing fees/rebroadcast of onchain transactions, the chance of attack
> success sounds high in my opinion.
>
> # Countermeasures
>
> Channel policies could be tighter, like bounded further down
> `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the
> latter, it's pretty hard as a) fee estimators diverge on mempool views b)
> an attacker can craft escape HTLC-txn in a period of high-fee and patiently
> waits a low-fee period to launch the exploitation.
>
> 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. But this sounds like introducing a griefing attack vector.
> Your counterparty can burn more of your lawful balance in fees than you'll
> punish its revoked balance.
>
> 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.
>
> Thoughts of further countermeasures ?
>
> I think the vulnerability described is mostly right but please point any
> missing details.
>
> Cheers,
>
> Antoine
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200910/24240038/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:00:51
in reply to nevent1q…zsl5
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:00:51Event JSON
{
"id": "3ef55ba28301241d13b2655e82a5aee233bf03b4c883a9b26ab4ee7329306c5a",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315651,
"kind": 1,
"tags": [
[
"e",
"9ccc8aef1955c5fc409383e6730393f44734353ad7590eb24e772b59fa8dd0e0",
"",
"root"
],
[
"e",
"16c30172f24a8fddf7a62f2f14c9ccc11b1a837467dca8111ef156acbe46a909",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2020-09-10\n📝 Original message:\nHi Antoine,\n\nGreat findings!\n\nI think an even simpler mitigation is just for the non-initiator to _reject_\nupdate_fee proposals that are \"unreasonable\". The non-initiator can run a\n\"fee leak calculation\" to compute the worst-case leakage of fees in the\nrevocation case. This can be done to day without any significant updates to\nimplementations, and some implementations may already be doing this.\n\nOne issue is that we don't have a way to do a \"soft reject\" of an update_fee\nas is. However, depending on the implementations, it may be possible to just\nreconnect and issue a co-op close if there're no HTLCs on the commitment\ntransaction.\n\nAs you mentioned by setting proper values for max allowed htlcs, max in\nflight, reserve, etc, nodes are able to quantify this fee leak risk ahead of\ntime, and set reasonable parameters based on their security model. One issue\nis that these values are set in stone rn when the channel is opened, but\nfuture iterations of dynamic commitments may allow us to update them on the\nfly.\n\nIn the mid-term, implementations can start to phase out usage of update_fee\nby setting a minimal commitment fee when the channel is first opened, then\nrelying on CPFP to bump up the commitment and any HTLCs if needed. This\ndiscovery might very well hasten the demise of update_fee in the protocol\nall together as well. I don't think we need to depend entirely on a\ntheoretical package relay Bitcoin p2p upgrade assuming implementations are\nwilling to make an assumption that say 20 sat/byte or w/e has a good chance\nof widespread propagation into mempools.\n\n\u003eFrom the perspective of channel safety, and variations of attacks like\n\"flood \u0026 loot\", imo it's absolutely critical that nodes are able to update\nthe fees on their second-level HTLC transactions. As this is where the real\ndanger lies: if nodes aren't able to get 2nd level HTLCs in the chain in\ntime, then the incoming HTLC expiry will expire, creating a race condition\nacross both commitments which can potentially cascade.\n\nIn lnd today, anchors is still behind a build flag, but we plan to enable\nit by default for our upcoming 0.12 release. The blockers on our end were to\nadd support for towers, and add basic deadline aware bumping, both of which\nare currently on track. We'll now also look into setting clamps on the\nreceiver end to just not accept unreasonable values for the fee rate of a\ncommitment, as this ends up eating into the true HTLC values for both sides.\n\n-- Laolu\n\n\nOn Thu, Sep 10, 2020 at 9:28 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e Hi,\n\u003e\n\u003e In this post, I would like to expose a potential vulnerability introduced\n\u003e by the recent anchor output spec update related to the new usage of\n\u003e SIGHASH_SINGLE for HTLC transactions. This new malleability combined with\n\u003e the currently deployed mechanism of `update_fee` is likely harmful for\n\u003e funds safety.\n\u003e\n\u003e This has been previously shared with deployed implementations devs, as\n\u003e anchor channels are flagged as experimental it's better to discuss and\n\u003e solve this publicly. That said, if you're currently running experimental\n\u003e anchor channels with non-trusted parties on mainnet, you might prefer to\n\u003e close them.\n\u003e\n\u003e # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)\n\u003e\n\u003e First, let's get started by a quick reminder of the data set committed by\n\u003e signature digest algorithm of Segwit transactions (BIP 143):\n\u003e * nVersion\n\u003e * hashPrevouts\n\u003e * hashSequence\n\u003e * outpoint\n\u003e * scriptCode of the input\n\u003e * value of the output spent by this input\n\u003e * nSequence of the input\n\u003e * hashOutputs\n\u003e * nLocktime\n\u003e * sighash type of the signature\n\u003e\n\u003e Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE\n\u003e | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus\n\u003e it can spend non-cooperatively its HTLC outputs on its commitment\n\u003e transactions. I.e when Alice broadcasts her commitment transaction, every\n\u003e Bob's signatures on Alice's HTLC-Success/Timeout transactions are now\n\u003e flagging the new sighash type.\n\u003e\n\u003e Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs`\n\u003e (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the\n\u003e output scriptpubkey/amount at the same index that\n\u003e the spending input. Alice is free to attach additional inputs/outputs to\n\u003e her HTLC transaction. This change is aiming to let a single-party bump the\n\u003e feerate of 2nd-stage HTLC transactions in case of mempool-congestion,\n\u003e without counterparty cooperation and thus make HTLC funds safer.\n\u003e\n\u003e The attached outputs are _not_ encumbered by a revokeable redeemscript for\n\u003e a potential punishment.\n\u003e\n\u003e That said, anchor ouput spec didn't change disable the current fee\n\u003e mechanism already covering HTLC transactions. Pre/post-anchor channels are\n\u003e negotiating a feerate through `update_fee` exchange, initiated by the\n\u003e channel funder. This `update_fee` can be rejected by the receiver if it's\n\u003e deemed unreasonable compared to your local fee estimator view, but as of\n\u003e today implementations are pretty liberal in their acceptance, admitting a\n\u003e divergence from a scale of 1 to no-bound at all.\n\u003e\n\u003e This negotiated feerate (`feerate_per_kw`) is used by channel participants\n\u003e to compute effective fees which have to be deduced either from the funder\n\u003e balance output for commitment transactions or from HTLC output value for\n\u003e HTLC transactions.\n\u003e\n\u003e # The Vulnerability : a Penalty Escape Vector\n\u003e\n\u003e By increasing the feerate thanks to `update_fee`, a malicious party can\n\u003e inflate fees committed on HTLC input/output pairs and redirect this\n\u003e inflated fee to a single-controlled output attached to these malleable\n\u003e pairs. This won't be punishable by an honest party in case of revoked state\n\u003e broadcast and thus enable to partially escape the penalty.\n\u003e\n\u003e As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw`\n\u003e is 10000 sats.\n\u003e\n\u003e At state N, Alice balance is all on her side. She announces 10 outgoing\n\u003e HTLCs of value 7000 sats.\n\u003e\n\u003e As Commitment tx weight with 10 outputs is 2844 (post-anchor), the\n\u003e absolute fee committed is 28440 sats.\n\u003e\n\u003e As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is\n\u003e of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat.\n\u003e This absolute fee aims to pay the miner fee in case Alice needs to timeout\n\u003e HTLC onchain.\n\u003e\n\u003e Her remaining balance is 1560 sat, above both dust_limit_satoshi and the\n\u003e channel reserve as constrained by Bob (likely 1%).\n\u003e\n\u003e Alice waits for HTLCs to expire and advances state to N+1. Then she\n\u003e empties her balance minus reserve by sending a HTLC relayed by Bob either\n\u003e to a colluding channel on the rest of network or back to an onchain address\n\u003e thanks to a swap service.\n\u003e\n\u003e At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost\n\u003e all of the absolute fee to a new P2WPKH output only controlled by her. She\n\u003e broadcasts the revoked commitment tx N and burns 28440 sats in commitment\n\u003e fee.\n\u003e\n\u003e Her balance of 1560 sats is punished by Bob's justice transaction.\n\u003e\n\u003e After confirmation and thus maturing of the CSV of 1 on her HTLC output\n\u003e Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to\n\u003e pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.\n\u003e\n\u003e Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560\n\u003e (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs\n\u003e fees) - 340*10 (HTLCs output) = 125600 sats.\n\u003e\n\u003e Alice's gain is superior at channel value as it has been partially\n\u003e double-spend by bypassing the revocation punishment.\n\u003e\n\u003e # Limitations of Attacker Success\n\u003e\n\u003e A first limitation of attack success which can be point of is the fact\n\u003e that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a\n\u003e honest party can punish this output before the malicious spend them with\n\u003e the revoked HTLC txn. In practice a malicious party can attach a branch of\n\u003e descendants to its anchor output and that way only allowing one more\n\u003e mempool victim's transaction on the revoked commitment. The victim must\n\u003e spend all outputs at once or otherwise they're going to obstrucate each\n\u003e other at mempool acceptance.\n\u003e\n\u003e Secondly, other limitations are the per-implementation channel policy\n\u003e `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and\n\u003e acceptance bound of `update_fee`. A quick look at default policies, even if\n\u003e they vary between deploy implementations, let it think there is room to\n\u003e escape a substantial part of channel value.\n\u003e\n\u003e Lastly, after the revoked commitment transaction is confirmed, both\n\u003e attacker and victim are in a feerate race to confirm either a justice\n\u003e transaction or a malicious HTLC-timeout. As fee estimator logic of the\n\u003e victim's implementation is a public piece of knowledge, it shouldn't be\n\u003e hard for the attacker to know the range of the first fee bid and override\n\u003e it by a bit to confirm it before the victim RBF at next block. Currently,\n\u003e not all implementations have RBF of justice transactions.\n\u003e\n\u003e As of today, if anchor output is deployed and given how LN implementations\n\u003e are managing fees/rebroadcast of onchain transactions, the chance of attack\n\u003e success sounds high in my opinion.\n\u003e\n\u003e # Countermeasures\n\u003e\n\u003e Channel policies could be tighter, like bounded further down\n\u003e `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the\n\u003e latter, it's pretty hard as a) fee estimators diverge on mempool views b)\n\u003e an attacker can craft escape HTLC-txn in a period of high-fee and patiently\n\u003e waits a low-fee period to launch the exploitation.\n\u003e\n\u003e Justice transactions can adopt a scorched earth approach binding their\n\u003e feerate to the max to increase odds of winning the feerate race and thus\n\u003e deter attackers. But this sounds like introducing a griefing attack vector.\n\u003e Your counterparty can burn more of your lawful balance in fees than you'll\n\u003e punish its revoked balance.\n\u003e\n\u003e A workable option would be to patch current anchor spec to remove\n\u003e `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing\n\u003e a minimal relay fee.\n\u003e\n\u003e Thoughts of further countermeasures ?\n\u003e\n\u003e I think the vulnerability described is mostly right but please point any\n\u003e missing details.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Antoine\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200910/24240038/attachment-0001.html\u003e",
"sig": "375564fc6f60dcb9c104f78994b0b0092c25920d3e18b750a589c9ddd9393569ff7e03d748869311f09b9d74d0e4bca6173a2fa0cc13c8e6acfa237a7aa1919f"
}