📅 Original date posted:2020-06-21
📝 Original message:
Hi Rene,
IMO this is mostly mitigated by anchor commitments. The impact of this
attack is predicated on the "victim" paying 5x on-chain fees (for their
confirmation target) to sweep all their HTLCs. Anchor commitments let the
initiator of the channel select a very low starting fee (just enough to get
into the mempool), and also let them actually bump the fees of second-level
HTLC transactions.
In addition to being able to pay much lower fees ("just enough" to get into
the chain), anchor commitments allow second-level HTLC _aggregation_, This
means that for HTLCs with the same expiry height, a peer is able to _batch_
them all into a single transaction, further saving on fees.
lnd shipped with a form of anchor commitments in our past major release
(v0.10.0-beta). In that release the format is opt in, and is enabled with a
startup command-line flag. For 0.11, we're planning on making this the
default commitment type, giving all users that update the ability to
_finally_ have proper fee control of their commitments, and second-level
HTLC transactions.
> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output)
One relevant detail here is that if the attacker is to attempt this with
minimal setup, then they'll need to be the ones that open the channel.
Since they're the initiator, they'll actually be the ones paying the fees
rendering this attempt moot.
Alternatively, they could use something like Lightning Loop to gain the
_outbound_ bandwidth (Loop In) needed to attempt this attack (using inbound
opened channels, but they'll need to pay for that bandwidth, adding a
further cost to the attack. Not to mention that they'll need to pay on-chain
fees to sweep the HTLCs they created themselves. In short, this attack isn't
costless as they'll need to acquire outbound liquidity for an incoming
channel, and also need to pay fees independent of the "success" of their
attack.
> I quote from BOLT 02 which suggests a buffer of a factor of 5
I'm not sure how many implementations actually follow this in practice.
FWIW, lnd doesn't.
> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.
No, the attacker is the one that needs to sweep these HTLCs, since they
offered them. This adds to their costs.
> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol
I don't think this is always the case. Depending on the minimum HTLC
settings in the channel (another mitigation), and the distribution of funds
in the channel, it may be the case that the victim doesn't have any funds in
the channel at all (everything was on the attacker's side). In that case,
the "victim" doesn't really care if this channel is clogged up as they
really have no stake in this channel.
> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot.
As mentioned above, gaining purely incoming channels doesn't allow the
attacker to launch this attack, as they'll be unable to _send out_ from any
of those channels.
> 1. The current solution is to just not use up the max value of htlc's.
> Eclaire and c-lightning by default only use up to 30 htlcs.
IMO, this isn't a solution. Lowering the max number of HTLCs in-flight just
makes it easier (lowers the capital costs) to jam a channel. The authors of
the paper you linked have another paper exploring these types of attacks
[1], and cite the _hard coded_ limit of 483 HTLCS as an enabling factor.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core
I think you're misinterpreting this PR, but see my first paragraph about
anchor commitments which that PR enables.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
Anchors let you do this ;)
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts.
This is already how "dust HTLCs" are calculated. The amount remaining from
the HTLC after it pays for its second-level transaction needs to be above
dust. This policy can be asymmetric across commitments in the channel.
> 5. Somehow be able to aggregate htlc's.
Anchors let you do this on the transaction level (MIMO 2nd level HTLC
transactions).
I hope other implementations join lnd in deploying anchor commitments to
mitigate nuisance attacks like this, and _finally_ give users better fee
control for channels and any off-chain contracts within those channels.
BTW, the "Flood & Loot" paper you linked mentions anchor commitments as a
solution towards the end of the paper. However, they erroneously state that
an attacker would be able to spend their HTLC with a _non replaceable_
transaction. This isn't the case since all redemption paths are encumbered
with a CSV delay of 1. This delay forces the attacker to spend the output
with an input that has a non-final sequence, meaning the transaction is
RBF-able.
[1]: https://arxiv.org/abs/2002.06564
-- Laolu
On Wed, Jun 17, 2020 at 3:30 AM René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hey everyone and of course good morning ZmnSCPxj (:
>
> about 11 months ago I discovered a potential blackmail attack with HTLCs
> after answering this question on stack exchange (c.f
> https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).
> This attack is similar to the one that was possible with tx malleability on
> the funding transaction without the segwit upgrade (c.f.
> https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&page=126).
> Meaning an attacker can force a victim to lose money and use this fact to
> blackmail the victim, to potentially gain / steal some of the lost funds.
>
> TL;DR:
> =====
> * Depending on the circumstances this attack allows an attacker to make
> channel partners lose a substantial amount of BTC without substantial costs
> for the attacker.
> * Depending on the exact circumstances this could be for example ~0.15
> BTC. In particular it demonstrates why opening a channel is not an entirely
> trustless activity.
> * The attacker will reliably only be able to force the victim to lose this
> amount of Bitcoin.
> * It is not clear how in practice the attacker could gain this amount or
> parts of it as this would involve not only game theory but also rather
> quick communication between attacker and victim and customized Lightning
> nodes which at least for the victim would be unlikely to exist.
> * None of the suggested fixes seems to be satisfying though the current
> solution of lowering the maximum amount of HTLCs that can concurrently be
> in flight seems to be a reasonable start for now.
>
>
> Timeline on Disclosure
> =================
> I have disclosed this attack on Sunday July 21st 2019 to Fabrice Drouin
> (and shortly after to Christian Decker) in a phone call who in turn has
> discussed it with people from the other implementations. From his feedback
> I understood that people working on implementations have been more or less
> aware of the possibility of this attack. Fabrice also mentioned that he
> believed implementations currently try to mitigate this by setting low
> limits of allowed / accepted HTLCs in flight. However at that time this was
> only true for e-clair. It is now also true for c-lightning and as far as I
> know still not true for lnd. Fabrice said that the people he talked to have
> suggested that I should eventually describe the attack in public to raise
> awareness (also from the group of node operators) for the problems related
> to this attack. He also suggested that - if I wanted to - I should update
> the rfc with recommendations and warnings. While I already have in mind
> how to change the rfc I wanted to start the discussion first. Maybe some
> people find better fixes than just a warning that I have in mind. So far I
> didn't do anything because I wanted to also give lnd the chance to handle
> the problem.
>
> There are two reasons I disclose this attack today:
> 1.) I think almost 1 year is enough time to do something about it. The
> only implementation that afaik didn't yet is lnd (see below) but I got
> roasbeefs ok last week to go ahead and publish the attack anyway so that we
> can have a broader discussion on mitigation strategies.
> 2.) The attack seems actually very similar to the one described in the
> "Flood & Loot: A Systemic Attack On The Lightning Network" - paper which
> came out 2 days ago (c.f.: https://arxiv.org/abs/2006.08513 ). I believe
> any person reading that paper will understand the possibility of the attack
> that I describe anyway so I believe it is now more or less public anyway
> and thus time for an open / public discussion.
>
> The main difference between the two attacks (if I understand this novel
> paper correctly) is: In the "flood and loot"-attack one tries to steal the
> HTLC output of the victims. Where in the "flood and blackmail"-attack that
> I describe I try to to force the victim to lose almost all its funds due to
> high on chain fees (Which I could use to blackmail the victim)
>
> Description of the attack
> ===================
> Let us assume the victim has funded a channel with an attacker meaning it
> will have to pay the fees for the commitment transaction in case of a force
> close.
>
> During a fee spike (let us assume fee estimators suggest 150 sat / byte)
> the attacker spams this channel with the maximum possible amount of HTLCs
> that the protocol allows. The HTLCs can be of a small value but need to be
> bigger than the dust limit so that additional outputs are actually added to
> the commitment transaction which makes it quite large in Bytes. According
> to the BOLTs these are 483 additional outputs to the commitment
> transaction.
> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output) For the actual attack it does not matter in which
> direction the HTLCs are spammed but economically the direction I propose
> makes even more sense for the attacker and can be achieved with circular
> onions.
>
> The attacked channel partner will happily - according to the protocol -
> use a higher fee than the current fee rate. I quote from BOLT 02 which
> suggests a buffer of a factor of 5
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee:
>
>
> > The node responsible for paying the Bitcoin fee [...] SHOULD send
> update_fee to ensure the current fee rate is sufficient (by a significant
> margin) for timely processing of the commitment transaction. [...] Given
> the variance in fees, and the fact that the transaction may be spent in the
> future, it's a good idea for the fee payer to keep a good margin (say 5x
> the expected fee requirement); but, due to differing methods of fee
> estimation, an exact value is not specified.
>
> This overpayment of fees will result in 750 sat / byte for this fee spike
> scenario. This is by the way not completely unrealistic [I recently opened
> a channel with 2.56 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/c0ac6cfe15e0d0c921362ab9fad998a8a8e16cd8d9d4159487dd69141ea2b9b0)
> and the channel was force closed a couple minutes later due to an
> implementation bug resulting in fees of 101.17 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/e32135315ec147bb27f771b2e15c7178ea573afd16cd4970bf814c9b18bc46e3
> )
>
> As far as I understand the appendix of BOLT 03 offered HTLCs are 43 Byte
> in size (c.f.:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights)
> resulting in the following additional fees for the spammed commitment
> transaction:
>
> fee (for 483 htlcs) = 483 * 43 byte * 750 sat / byte = 15576750 sat =
> 0.1557675 BTC
>
> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.
>
> Once all HTLCs are set up the attacker will stop signing commitment
> transactions. In the beginning this is not suspicious as the HTLCs will
> take some time to settle anyway. But also when fees go down and the victim
> who funded the channel wants to update the fees the attacker will just not
> be responsive. Eventually the victim will dare to force close the channel
> with all those expensive HTLCs.
>
> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol:
> "Either you will pay those 0.1557675 BTC of fees or we will collaboratively
> close the channel but that will cost you part of the amount you lost." Game
> theory suggests that the attacker will be able to claim the major fraction
> of the BTC (c.f. https://en.wikipedia.org/wiki/Ultimatum_game that are
> frozen in tx fees as the victim effectively already has lost that money and
> can only gain something back.
>
>
> Thoughts
> =======
> You might say that the blackmail part of this attack is unrealistic as the
> blackmailing person will not have enough time to successfully do the
> blackmail as the channel that is not operational will fail.
>
> 1.) The only thing that lightning nodes might do is a fee update as the
> htlcs stuffed the channel so I believe there is actually some time to
> contact the victim.
> 2.) What if the attacker is a mining pool who is just interested in high
> fees who does not even need to do the blackmailing stuff but will just
> force close the channel once the htlcs are set up?
> 3.) The attacker might not even be interested in blackmailing the victim.
> The attacker could just be interested in harming the victim. Though it
> might certainly be a challenge to target a specific victim and trick it
> into opening a channel with an attacker.
>
> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot. an
> attacker can start by creating many channels making him a highly likely
> channel partner for autopilot users (who will also fund the channel). Such
> a highly connected node might also be interesting for non autopilot users.
>
> Implementations
> ============
>
> I looked at the code myself. I hope I do oversee things but to me it looks
> like only eclaire was somehow mitigating this attack from being exploited.
> (by a default config of 30 accepted htlcs which will protect the average
> user and is much lower than the 483) and c-lightning has merged a patch
> from me which I provided after I disclosed the attack:
>
> ## clightning:
>
> c-lightning did not by default set a hard cap on htlcs before version
> 0.7.2 but then merged my patch
> https://github.com/ElementsProject/lightning/pull/2858 which tried to
> resemble the eclair defaults
>
> ## eclaire:
>
> the max accepted htlc value per channel is set as a constant to 483 which
> follows the recommendation of the BOLTs:
>
> https://github.com/ACINQ/eclair/blob/e62adf2deae213d2cd0f2a6874227dcfc57880ae/eclair-core/src/main/scala/fr/acinq/eclair/channel/Channel.scala#L52
>
> The value is tested against at:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L99
>
> and:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L132
>
> and:
>
> https://github.com/ACINQ/eclair/blob/93d9369f900766171f2ddf579e8b12e28d8f0d25/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L154
>
> However the default config file specifies a maximum amount of 30 accepted
> htlcs at:
>
> https://github.com/ACINQ/eclair/blob/9afb26e09c69dd5d6a14732baf5dcdf2b7a9142b/eclair-core/src/main/resources/reference.conf#L62
>
>
> ## lnd
> It seems like lnd did not and last time I checked (maybe I oversaw
> something) does not set a hard cap on htlcs by default. The way how I
> understand the code they allow up to 483 htlcs by default:
>
> The test when adding an htlc if it is beyond the maximum accepted values
> is here:
>
> https://github.com/lightningnetwork/lnd/blob/970d7604071baae227db42d4665ef9d1b56988e8/lnwallet/channel.go#L3795
>
> the default configuration seems to be here (and in the most recent commit
> the line still exists):
>
> https://github.com/lightningnetwork/lnd/blob/8b04cfbf12f460853e8c55611cd1bba21b1510ef/input/size.go#L187
>
> the software will accept up to 483 htlcs according to this line:
>
> https://github.com/lightningnetwork/lnd/blob/111cbeaa990cba78563d6cc8c19b152e2d3042f6/lnwallet/reservation.go#L314
>
> I could not find any spec lower than that in the suggested sample config
> at:
> https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf
>
>
> Ideas for Fixes
> ===========
>
> I am completely unhappy with each of the following ideas. I hope you will
> come up with smarter solutions. I believe the solution is not obvious. Thus
> I thought it makes sense in the brainstorm phase to even post some ideas
> with obvious drawbacks.
>
> 1. The current solution is to just not use up the max value of
> htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core (c.f.
> https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get
> it correctly with that we could always have low fees and ask the person who
> want to claim their outputs to pay fees. This excludes overpayment and
> could happen at a later stage when fees are not spiked. Still the victim
> who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts. This would
> at least make the attack expensive as the attacker would have to bind a lot
> of liquidity.
> 5. Somehow be able to aggregate htlc's. In a world where we use payment
> points instead of preimages we might be able to do so. It would be really
> cool if separate HTLC's could be combined to 1 single output. I played
> around a little bit but I have not come up with a scheme that is more
> compact in all cases. Thus I just threw in the idea.
> 6. Split onchain fees differently (now the attacker would also lose fees
> by conducting this attack) - No I don't want to start yet another fee
> bikeshadding debate. (In particular I believe that a different split of
> fees might make the Flood & Loot attack economically more viable which
> relies on the same principle)
>
> Independently I think we should have a hint in our readme file about where
> and how people can disclose attacks and vulnerabilities. Implementations
> have this but the BOLTs do not.
>
> with kind regards Rene
>
> --
>
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
> _______________________________________________
> 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/20200621/992826d6/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:00:27
in reply to nevent1q…6ds8
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:00:27Event JSON
{
"id": "18af20826241065c17e56372200c5c9acbf40dc6b5d8e5ce2e33d288b0cf83bf",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315627,
"kind": 1,
"tags": [
[
"e",
"7da926da548374ca4e339ba53f58494be25da0200ace1f92f2de9ac4672123e5",
"",
"root"
],
[
"e",
"d4c4a11d86d7b3f0aabad6db3e83e82e1cb490e66f32f684212e211e0dedc9c0",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2020-06-21\n📝 Original message:\nHi Rene,\n\nIMO this is mostly mitigated by anchor commitments. The impact of this\nattack is predicated on the \"victim\" paying 5x on-chain fees (for their\nconfirmation target) to sweep all their HTLCs. Anchor commitments let the\ninitiator of the channel select a very low starting fee (just enough to get\ninto the mempool), and also let them actually bump the fees of second-level\nHTLC transactions.\n\nIn addition to being able to pay much lower fees (\"just enough\" to get into\nthe chain), anchor commitments allow second-level HTLC _aggregation_, This\nmeans that for HTLCs with the same expiry height, a peer is able to _batch_\nthem all into a single transaction, further saving on fees.\n\nlnd shipped with a form of anchor commitments in our past major release\n(v0.10.0-beta). In that release the format is opt in, and is enabled with a\nstartup command-line flag. For 0.11, we're planning on making this the\ndefault commitment type, giving all users that update the ability to\n_finally_ have proper fee control of their commitments, and second-level\nHTLC transactions.\n\n\u003e The direction of HTLCs are chosen so that the amount is taken from the\n\u003e `to_remote` output of the attacker (obviously on the victims side it will\n\u003e be the `to_local` output)\n\nOne relevant detail here is that if the attacker is to attempt this with\nminimal setup, then they'll need to be the ones that open the channel.\nSince they're the initiator, they'll actually be the ones paying the fees\nrendering this attempt moot.\n\nAlternatively, they could use something like Lightning Loop to gain the\n_outbound_ bandwidth (Loop In) needed to attempt this attack (using inbound\nopened channels, but they'll need to pay for that bandwidth, adding a\nfurther cost to the attack. Not to mention that they'll need to pay on-chain\nfees to sweep the HTLCs they created themselves. In short, this attack isn't\ncostless as they'll need to acquire outbound liquidity for an incoming\nchannel, and also need to pay fees independent of the \"success\" of their\nattack.\n\n\u003e I quote from BOLT 02 which suggests a buffer of a factor of 5\n\nI'm not sure how many implementations actually follow this in practice.\nFWIW, lnd doesn't.\n\n\u003e Additionally the victim will also have to swipe all offered HTLCs (which\n\u003e will be additional costs but could be done once the fees came down) so we\n\u003e neglect them.\n\nNo, the attacker is the one that needs to sweep these HTLCs, since they\noffered them. This adds to their costs.\n\n\u003e Knowing that this will happen and that the victim has to spend those funds\n\u003e (publishing old state obviously does not work!) the attacker has a time\n\u003e window to blackmail the victim outside of the lightning network protocol\n\nI don't think this is always the case. Depending on the minimum HTLC\nsettings in the channel (another mitigation), and the distribution of funds\nin the channel, it may be the case that the victim doesn't have any funds in\nthe channel at all (everything was on the attacker's side). In that case,\nthe \"victim\" doesn't really care if this channel is clogged up as they\nreally have no stake in this channel.\n\n\u003e Also you might say that an attacker needs many incoming channels to\n\u003e execute this attack. This can be achieved by gaming the autopilot.\n\nAs mentioned above, gaining purely incoming channels doesn't allow the\nattacker to launch this attack, as they'll be unable to _send out_ from any\nof those channels.\n\n\u003e 1. The current solution is to just not use up the max value of htlc's.\n\u003e Eclaire and c-lightning by default only use up to 30 htlcs.\n\nIMO, this isn't a solution. Lowering the max number of HTLCs in-flight just\nmakes it easier (lowers the capital costs) to jam a channel. The authors of\nthe paper you linked have another paper exploring these types of attacks\n[1], and cite the _hard coded_ limit of 483 HTLCS as an enabling factor.\n\n\u003e 2. Probably the best fix (not sure if I understand the consequences\n\u003e correctly) is coming from this PR to bitcoin core\n\nI think you're misinterpreting this PR, but see my first paragraph about\nanchor commitments which that PR enables.\n\n\u003e 3. Don't overpay fees in commitment transactions. We can't foresee the\n\u003e future anyway\n\nAnchors let you do this ;)\n\n\u003e 4. Don't add htlcs for which the on chain fee is higher than the HTLCs\n\u003e value (like we do with sub dust amounts and sub satoshi amounts.\n\nThis is already how \"dust HTLCs\" are calculated. The amount remaining from\nthe HTLC after it pays for its second-level transaction needs to be above\ndust. This policy can be asymmetric across commitments in the channel.\n\n\u003e 5. Somehow be able to aggregate htlc's.\n\nAnchors let you do this on the transaction level (MIMO 2nd level HTLC\ntransactions).\n\nI hope other implementations join lnd in deploying anchor commitments to\nmitigate nuisance attacks like this, and _finally_ give users better fee\ncontrol for channels and any off-chain contracts within those channels.\n\nBTW, the \"Flood \u0026 Loot\" paper you linked mentions anchor commitments as a\nsolution towards the end of the paper. However, they erroneously state that\nan attacker would be able to spend their HTLC with a _non replaceable_\ntransaction. This isn't the case since all redemption paths are encumbered\nwith a CSV delay of 1. This delay forces the attacker to spend the output\nwith an input that has a non-final sequence, meaning the transaction is\nRBF-able.\n\n[1]: https://arxiv.org/abs/2002.06564\n\n-- Laolu\n\n\nOn Wed, Jun 17, 2020 at 3:30 AM René Pickhardt via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hey everyone and of course good morning ZmnSCPxj (:\n\u003e\n\u003e about 11 months ago I discovered a potential blackmail attack with HTLCs\n\u003e after answering this question on stack exchange (c.f\n\u003e https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).\n\u003e This attack is similar to the one that was possible with tx malleability on\n\u003e the funding transaction without the segwit upgrade (c.f.\n\u003e https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf\u0026page=126).\n\u003e Meaning an attacker can force a victim to lose money and use this fact to\n\u003e blackmail the victim, to potentially gain / steal some of the lost funds.\n\u003e\n\u003e TL;DR:\n\u003e =====\n\u003e * Depending on the circumstances this attack allows an attacker to make\n\u003e channel partners lose a substantial amount of BTC without substantial costs\n\u003e for the attacker.\n\u003e * Depending on the exact circumstances this could be for example ~0.15\n\u003e BTC. In particular it demonstrates why opening a channel is not an entirely\n\u003e trustless activity.\n\u003e * The attacker will reliably only be able to force the victim to lose this\n\u003e amount of Bitcoin.\n\u003e * It is not clear how in practice the attacker could gain this amount or\n\u003e parts of it as this would involve not only game theory but also rather\n\u003e quick communication between attacker and victim and customized Lightning\n\u003e nodes which at least for the victim would be unlikely to exist.\n\u003e * None of the suggested fixes seems to be satisfying though the current\n\u003e solution of lowering the maximum amount of HTLCs that can concurrently be\n\u003e in flight seems to be a reasonable start for now.\n\u003e\n\u003e\n\u003e Timeline on Disclosure\n\u003e =================\n\u003e I have disclosed this attack on Sunday July 21st 2019 to Fabrice Drouin\n\u003e (and shortly after to Christian Decker) in a phone call who in turn has\n\u003e discussed it with people from the other implementations. From his feedback\n\u003e I understood that people working on implementations have been more or less\n\u003e aware of the possibility of this attack. Fabrice also mentioned that he\n\u003e believed implementations currently try to mitigate this by setting low\n\u003e limits of allowed / accepted HTLCs in flight. However at that time this was\n\u003e only true for e-clair. It is now also true for c-lightning and as far as I\n\u003e know still not true for lnd. Fabrice said that the people he talked to have\n\u003e suggested that I should eventually describe the attack in public to raise\n\u003e awareness (also from the group of node operators) for the problems related\n\u003e to this attack. He also suggested that - if I wanted to - I should update\n\u003e the rfc with recommendations and warnings. While I already have in mind\n\u003e how to change the rfc I wanted to start the discussion first. Maybe some\n\u003e people find better fixes than just a warning that I have in mind. So far I\n\u003e didn't do anything because I wanted to also give lnd the chance to handle\n\u003e the problem.\n\u003e\n\u003e There are two reasons I disclose this attack today:\n\u003e 1.) I think almost 1 year is enough time to do something about it. The\n\u003e only implementation that afaik didn't yet is lnd (see below) but I got\n\u003e roasbeefs ok last week to go ahead and publish the attack anyway so that we\n\u003e can have a broader discussion on mitigation strategies.\n\u003e 2.) The attack seems actually very similar to the one described in the\n\u003e \"Flood \u0026 Loot: A Systemic Attack On The Lightning Network\" - paper which\n\u003e came out 2 days ago (c.f.: https://arxiv.org/abs/2006.08513 ). I believe\n\u003e any person reading that paper will understand the possibility of the attack\n\u003e that I describe anyway so I believe it is now more or less public anyway\n\u003e and thus time for an open / public discussion.\n\u003e\n\u003e The main difference between the two attacks (if I understand this novel\n\u003e paper correctly) is: In the \"flood and loot\"-attack one tries to steal the\n\u003e HTLC output of the victims. Where in the \"flood and blackmail\"-attack that\n\u003e I describe I try to to force the victim to lose almost all its funds due to\n\u003e high on chain fees (Which I could use to blackmail the victim)\n\u003e\n\u003e Description of the attack\n\u003e ===================\n\u003e Let us assume the victim has funded a channel with an attacker meaning it\n\u003e will have to pay the fees for the commitment transaction in case of a force\n\u003e close.\n\u003e\n\u003e During a fee spike (let us assume fee estimators suggest 150 sat / byte)\n\u003e the attacker spams this channel with the maximum possible amount of HTLCs\n\u003e that the protocol allows. The HTLCs can be of a small value but need to be\n\u003e bigger than the dust limit so that additional outputs are actually added to\n\u003e the commitment transaction which makes it quite large in Bytes. According\n\u003e to the BOLTs these are 483 additional outputs to the commitment\n\u003e transaction.\n\u003e The direction of HTLCs are chosen so that the amount is taken from the\n\u003e `to_remote` output of the attacker (obviously on the victims side it will\n\u003e be the `to_local` output) For the actual attack it does not matter in which\n\u003e direction the HTLCs are spammed but economically the direction I propose\n\u003e makes even more sense for the attacker and can be achieved with circular\n\u003e onions.\n\u003e\n\u003e The attacked channel partner will happily - according to the protocol -\n\u003e use a higher fee than the current fee rate. I quote from BOLT 02 which\n\u003e suggests a buffer of a factor of 5\n\u003e https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee:\n\u003e\n\u003e\n\u003e \u003e The node responsible for paying the Bitcoin fee [...] SHOULD send\n\u003e update_fee to ensure the current fee rate is sufficient (by a significant\n\u003e margin) for timely processing of the commitment transaction. [...] Given\n\u003e the variance in fees, and the fact that the transaction may be spent in the\n\u003e future, it's a good idea for the fee payer to keep a good margin (say 5x\n\u003e the expected fee requirement); but, due to differing methods of fee\n\u003e estimation, an exact value is not specified.\n\u003e\n\u003e This overpayment of fees will result in 750 sat / byte for this fee spike\n\u003e scenario. This is by the way not completely unrealistic [I recently opened\n\u003e a channel with 2.56 sat / byte (c.f.:\n\u003e https://www.smartbit.com.au/tx/c0ac6cfe15e0d0c921362ab9fad998a8a8e16cd8d9d4159487dd69141ea2b9b0)\n\u003e and the channel was force closed a couple minutes later due to an\n\u003e implementation bug resulting in fees of 101.17 sat / byte (c.f.:\n\u003e https://www.smartbit.com.au/tx/e32135315ec147bb27f771b2e15c7178ea573afd16cd4970bf814c9b18bc46e3\n\u003e )\n\u003e\n\u003e As far as I understand the appendix of BOLT 03 offered HTLCs are 43 Byte\n\u003e in size (c.f.:\n\u003e https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights)\n\u003e resulting in the following additional fees for the spammed commitment\n\u003e transaction:\n\u003e\n\u003e fee (for 483 htlcs) = 483 * 43 byte * 750 sat / byte = 15576750 sat =\n\u003e 0.1557675 BTC\n\u003e\n\u003e Additionally the victim will also have to swipe all offered HTLCs (which\n\u003e will be additional costs but could be done once the fees came down) so we\n\u003e neglect them.\n\u003e\n\u003e Once all HTLCs are set up the attacker will stop signing commitment\n\u003e transactions. In the beginning this is not suspicious as the HTLCs will\n\u003e take some time to settle anyway. But also when fees go down and the victim\n\u003e who funded the channel wants to update the fees the attacker will just not\n\u003e be responsive. Eventually the victim will dare to force close the channel\n\u003e with all those expensive HTLCs.\n\u003e\n\u003e Knowing that this will happen and that the victim has to spend those funds\n\u003e (publishing old state obviously does not work!) the attacker has a time\n\u003e window to blackmail the victim outside of the lightning network protocol:\n\u003e \"Either you will pay those 0.1557675 BTC of fees or we will collaboratively\n\u003e close the channel but that will cost you part of the amount you lost.\" Game\n\u003e theory suggests that the attacker will be able to claim the major fraction\n\u003e of the BTC (c.f. https://en.wikipedia.org/wiki/Ultimatum_game that are\n\u003e frozen in tx fees as the victim effectively already has lost that money and\n\u003e can only gain something back.\n\u003e\n\u003e\n\u003e Thoughts\n\u003e =======\n\u003e You might say that the blackmail part of this attack is unrealistic as the\n\u003e blackmailing person will not have enough time to successfully do the\n\u003e blackmail as the channel that is not operational will fail.\n\u003e\n\u003e 1.) The only thing that lightning nodes might do is a fee update as the\n\u003e htlcs stuffed the channel so I believe there is actually some time to\n\u003e contact the victim.\n\u003e 2.) What if the attacker is a mining pool who is just interested in high\n\u003e fees who does not even need to do the blackmailing stuff but will just\n\u003e force close the channel once the htlcs are set up?\n\u003e 3.) The attacker might not even be interested in blackmailing the victim.\n\u003e The attacker could just be interested in harming the victim. Though it\n\u003e might certainly be a challenge to target a specific victim and trick it\n\u003e into opening a channel with an attacker.\n\u003e\n\u003e Also you might say that an attacker needs many incoming channels to\n\u003e execute this attack. This can be achieved by gaming the autopilot. an\n\u003e attacker can start by creating many channels making him a highly likely\n\u003e channel partner for autopilot users (who will also fund the channel). Such\n\u003e a highly connected node might also be interesting for non autopilot users.\n\u003e\n\u003e Implementations\n\u003e ============\n\u003e\n\u003e I looked at the code myself. I hope I do oversee things but to me it looks\n\u003e like only eclaire was somehow mitigating this attack from being exploited.\n\u003e (by a default config of 30 accepted htlcs which will protect the average\n\u003e user and is much lower than the 483) and c-lightning has merged a patch\n\u003e from me which I provided after I disclosed the attack:\n\u003e\n\u003e ## clightning:\n\u003e\n\u003e c-lightning did not by default set a hard cap on htlcs before version\n\u003e 0.7.2 but then merged my patch\n\u003e https://github.com/ElementsProject/lightning/pull/2858 which tried to\n\u003e resemble the eclair defaults\n\u003e\n\u003e ## eclaire:\n\u003e\n\u003e the max accepted htlc value per channel is set as a constant to 483 which\n\u003e follows the recommendation of the BOLTs:\n\u003e\n\u003e https://github.com/ACINQ/eclair/blob/e62adf2deae213d2cd0f2a6874227dcfc57880ae/eclair-core/src/main/scala/fr/acinq/eclair/channel/Channel.scala#L52\n\u003e\n\u003e The value is tested against at:\n\u003e\n\u003e https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L99\n\u003e\n\u003e and:\n\u003e\n\u003e https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L132\n\u003e\n\u003e and:\n\u003e\n\u003e https://github.com/ACINQ/eclair/blob/93d9369f900766171f2ddf579e8b12e28d8f0d25/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L154\n\u003e\n\u003e However the default config file specifies a maximum amount of 30 accepted\n\u003e htlcs at:\n\u003e\n\u003e https://github.com/ACINQ/eclair/blob/9afb26e09c69dd5d6a14732baf5dcdf2b7a9142b/eclair-core/src/main/resources/reference.conf#L62\n\u003e\n\u003e\n\u003e ## lnd\n\u003e It seems like lnd did not and last time I checked (maybe I oversaw\n\u003e something) does not set a hard cap on htlcs by default. The way how I\n\u003e understand the code they allow up to 483 htlcs by default:\n\u003e\n\u003e The test when adding an htlc if it is beyond the maximum accepted values\n\u003e is here:\n\u003e\n\u003e https://github.com/lightningnetwork/lnd/blob/970d7604071baae227db42d4665ef9d1b56988e8/lnwallet/channel.go#L3795\n\u003e\n\u003e the default configuration seems to be here (and in the most recent commit\n\u003e the line still exists):\n\u003e\n\u003e https://github.com/lightningnetwork/lnd/blob/8b04cfbf12f460853e8c55611cd1bba21b1510ef/input/size.go#L187\n\u003e\n\u003e the software will accept up to 483 htlcs according to this line:\n\u003e\n\u003e https://github.com/lightningnetwork/lnd/blob/111cbeaa990cba78563d6cc8c19b152e2d3042f6/lnwallet/reservation.go#L314\n\u003e\n\u003e I could not find any spec lower than that in the suggested sample config\n\u003e at:\n\u003e https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf\n\u003e\n\u003e\n\u003e Ideas for Fixes\n\u003e ===========\n\u003e\n\u003e I am completely unhappy with each of the following ideas. I hope you will\n\u003e come up with smarter solutions. I believe the solution is not obvious. Thus\n\u003e I thought it makes sense in the brainstorm phase to even post some ideas\n\u003e with obvious drawbacks.\n\u003e\n\u003e 1. The current solution is to just not use up the max value of\n\u003e htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.\n\u003e 2. Probably the best fix (not sure if I understand the consequences\n\u003e correctly) is coming from this PR to bitcoin core (c.f.\n\u003e https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get\n\u003e it correctly with that we could always have low fees and ask the person who\n\u003e want to claim their outputs to pay fees. This excludes overpayment and\n\u003e could happen at a later stage when fees are not spiked. Still the victim\n\u003e who offered the htlcs would have to spend those outputs at some time.\n\u003e 3. Don't overpay fees in commitment transactions. We can't foresee the\n\u003e future anyway\n\u003e 4. Don't add htlcs for which the on chain fee is higher than the HTLCs\n\u003e value (like we do with sub dust amounts and sub satoshi amounts. This would\n\u003e at least make the attack expensive as the attacker would have to bind a lot\n\u003e of liquidity.\n\u003e 5. Somehow be able to aggregate htlc's. In a world where we use payment\n\u003e points instead of preimages we might be able to do so. It would be really\n\u003e cool if separate HTLC's could be combined to 1 single output. I played\n\u003e around a little bit but I have not come up with a scheme that is more\n\u003e compact in all cases. Thus I just threw in the idea.\n\u003e 6. Split onchain fees differently (now the attacker would also lose fees\n\u003e by conducting this attack) - No I don't want to start yet another fee\n\u003e bikeshadding debate. (In particular I believe that a different split of\n\u003e fees might make the Flood \u0026 Loot attack economically more viable which\n\u003e relies on the same principle)\n\u003e\n\u003e Independently I think we should have a hint in our readme file about where\n\u003e and how people can disclose attacks and vulnerabilities. Implementations\n\u003e have this but the BOLTs do not.\n\u003e\n\u003e with kind regards Rene\n\u003e\n\u003e --\n\u003e\n\u003e https://www.rene-pickhardt.de\n\u003e\n\u003e Skype: rene.pickhardt\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/20200621/992826d6/attachment-0001.html\u003e",
"sig": "da5274d474591ffccc71969c5551e873513b14151c0d199c6c518786f562ac69cb433bb9b2e757b252112a15a3ac303a39c67b32a248be1045cb82dff2b289c2"
}