Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Jeremy]

Yes -- to be clear, most of the feature-wise benefits of CTV for Lightning
are only in the initial channel setup phase, lessening interactivity
requirements.

Everything else can be emulated via multisig layers, but that can add
substantial latency in doing either 2pECDSA for each layer or on chain &
storage overhead in the signature space. CTV helps here because it can be
both deterministic & compact, but is not adding a new feature to already
interactive protocols. This does end up helping in terms of the feasibility
of some of the HTLC indirection tree techniques though :).

--
@JeremyRubin 



On Sun, Jun 21, 2020 at 6:20 PM Olaoluwa Osuntokun 
wrote:

> Hi Jeremy,
>
> The up-front costs can be further mitigated even without something like CTV
> (which makes things more efficient) by adding a layer of in-direction
> w.r.t how
> HTLCs are manifested within the commitment transactions. To do this, we
> add a
> new 2-of-2 multi-sig output (an HTLC indirect block) to the commitment
> transactions. This is then spent by a new transaction (the HTLC block) that
> actually manifests (creates the HTLC outputs) the HTLCs.
>
> With this change, the cost to have a commitment be mined in the chain is
> now
> _independent of the number of HTLCs in the channel_. In the past I've
> called
> this construction "coupe commitments" (lol).
>
> Other flavors of this technique are possible as well, allowing both sides
> to
> craft varying HTLC indirection trees (double layers of indirection are
> possible, etc) which may factor in traits like HTLC expiration time (HTLCs
> that
> expire later are further down in the tree).
>
> Something like CTV does indeed make this technique more powerful+efficient
> as
> it allows one to succinctly commit to all the relevant desirable
> combinations
> of HTLC indirect blocks, and HTLC fan-out transactions.
>
> -- Laolu
>
>
> On Sat, Jun 20, 2020 at 4:14 PM Jeremy  wrote:
>
>> I am not steeped enough in Lightning Protocol issues to get the full
>> design space, but I'm fairly certain BIP-119 Congestion Control trees would
>> help with this issue.
>>
>> You can bucket a tree by doing a histogram of HTLC size, so that all
>> small HTLCs live in a common CTV subtree and don't interfere with higher
>> value HTLCs. You can also play with sequencing to prevent those HTLCs from
>> getting longchains in the mempool until they're above a certain value.
>> --
>> @JeremyRubin 
>> 
>>
>>
>> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard 
>> wrote:
>>
>>> Hi Rene,
>>>
>>> Thanks for disclosing this vulnerability,
>>>
>>> I think this blackmail scenario holds but sadly there is a lower
>>> scenario.
>>>
>>> Both "Flood & Loot" and your blackmail attack rely on `update_fee`
>>> mechanism and unbounded commitment transaction size inflation. Though the
>>> first to provoke block congestion and yours to lockdown in-flight fees as
>>> funds hostage situation.
>>>
>>> > 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.
>>>
>>> As of today, yes I would recommend capping commitment size both for
>>> ensuring competitive propagation/block selection and limiting HTLC exposure.
>>>
>>> > 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.
>>>
>>> It's a bit more complex, carve-out output, even combined with anchor
>>> output support on the LN-side won't protect against different flavors of
>>> pinning. I invite you to go through logs of past 2 LN dev meetings.
>>>
>>> > 3. Don't overpay fees in commitment transactions. We can't foresee the
>>> future anyway
>>>
>>> Once 2. is well-addressed we may deprecate `update_fee`.
>>>
>>> > 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.
>>>
>>> Ideally we want dust_limit to be dynamic, dust cap should be based on
>>> HTLC economic value, feerate of its output, feerate of HTLC-transaction,
>>> feerate estimation of any CPFP to bump it. I think that's kind of worthy to
>>> do once we solved 3. and 4
>>>
>>> > 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 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[David A. Harding]

On Sun, Jun 21, 2020 at 06:09:28PM -0700, Olaoluwa Osuntokun wrote:
> 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.  

I think the attack is more clearly stated in absolute terms.  An
attacker can force a victim to pay for 483 P2WSH outputs (each 43
vbytes), or a total of about 20,000 vbytes (plus regular overhead).

20769 = 43 * 483

During the post-halving feerate spike just a few weeks ago, paying 100
base units ("satoshis") per vbyte was plausible to ensure the commitment
transaction confirmed quickly.  At $9,500 USD/BTC, that's almost $200
USD.

197.3055 = 20769 * 100 / 1e8 * 9500

With a 5x multiplier, that's horrible, but even with no multiplier, it's
not good.  Moreover, a patient attacker can wait for a fee spike and
then attack multiple channels at once so that they compete against each
other for block space, potentially raising feerates even higher.

> 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.

(I was initially confused by this, so for anyone else confused by this,
the batching being described here is sort of the inverse of normal
payment batching.  Normally when you batch together multiple payments,
you use one input to pay more outputs than you would with separate
transactions.  Here, you still need to use the same number of inputs you
would to resolve HTLCs in separate ransactions (because each HTLC is a
separate UTXO), but you pay a single output.  This works and is indeed a
nice optimization.)

> Alternatively, they could use something like Lightning Loop to gain the
> _outbound_ bandwidth (Loop In) 

I don't think the attacker needs outbound bandwidth.  As implied in
René's post ("achieved with circular onions"), if the attacker is
Mallory and the victim is Bob, there just needs to be a circuit like:

Mallory → Alice → Bob → Mallory

Mallory can always settle with Alice offchain after Bob's timeout,
preventing Mallory from losing any money in the attack or from having to
pay for liquidity.  IIUC, Mallory's only cost would be paying for LN
routing fees and the time value of locking up her money until the
settlement.

> No, the attacker is the one that needs to sweep these HTLCs, since they
> offered them. This adds to their costs.

As described above, the attacker doesn't need to offer the HTLCs, they
can simply route a payment through any of the victim's other channels.

If the attacker does that, then the victim needs to pay onchain fees to
recover any remaining value in those HTLCs, potentially making this
attack two or three times more costly for the victim.

> > 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. 

It looks to me like an easy and effective solution to turn a ~$200
downside into a ~$20 downside (at 100 base units/vbyte).  It's certainly
has other downsides too, but I'm personally more concerned about losing
money than I am about having my channel jammed (and if jamming at 483
HTLCs is an issue, then hopefully the mitigation for that (e.g. upfront
fees) will make jamming at HTLCs a non-issue as well).

-Dave


signature.asc
Description: PGP signature
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Olaoluwa Osuntokun]

Hi Jeremy,

The up-front costs can be further mitigated even without something like CTV
(which makes things more efficient) by adding a layer of in-direction w.r.t
how
HTLCs are manifested within the commitment transactions. To do this, we add
a
new 2-of-2 multi-sig output (an HTLC indirect block) to the commitment
transactions. This is then spent by a new transaction (the HTLC block) that
actually manifests (creates the HTLC outputs) the HTLCs.

With this change, the cost to have a commitment be mined in the chain is now
_independent of the number of HTLCs in the channel_. In the past I've called
this construction "coupe commitments" (lol).

Other flavors of this technique are possible as well, allowing both sides to
craft varying HTLC indirection trees (double layers of indirection are
possible, etc) which may factor in traits like HTLC expiration time (HTLCs
that
expire later are further down in the tree).

Something like CTV does indeed make this technique more powerful+efficient
as
it allows one to succinctly commit to all the relevant desirable
combinations
of HTLC indirect blocks, and HTLC fan-out transactions.

-- Laolu


On Sat, Jun 20, 2020 at 4:14 PM Jeremy  wrote:

> I am not steeped enough in Lightning Protocol issues to get the full
> design space, but I'm fairly certain BIP-119 Congestion Control trees would
> help with this issue.
>
> You can bucket a tree by doing a histogram of HTLC size, so that all small
> HTLCs live in a common CTV subtree and don't interfere with higher value
> HTLCs. You can also play with sequencing to prevent those HTLCs from
> getting longchains in the mempool until they're above a certain value.
> --
> @JeremyRubin 
> 
>
>
> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard 
> wrote:
>
>> Hi Rene,
>>
>> Thanks for disclosing this vulnerability,
>>
>> I think this blackmail scenario holds but sadly there is a lower scenario.
>>
>> Both "Flood & Loot" and your blackmail attack rely on `update_fee`
>> mechanism and unbounded commitment transaction size inflation. Though the
>> first to provoke block congestion and yours to lockdown in-flight fees as
>> funds hostage situation.
>>
>> > 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.
>>
>> As of today, yes I would recommend capping commitment size both for
>> ensuring competitive propagation/block selection and limiting HTLC exposure.
>>
>> > 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.
>>
>> It's a bit more complex, carve-out output, even combined with anchor
>> output support on the LN-side won't protect against different flavors of
>> pinning. I invite you to go through logs of past 2 LN dev meetings.
>>
>> > 3. Don't overpay fees in commitment transactions. We can't foresee the
>> future anyway
>>
>> Once 2. is well-addressed we may deprecate `update_fee`.
>>
>> > 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.
>>
>> Ideally we want dust_limit to be dynamic, dust cap should be based on
>> HTLC economic value, feerate of its output, feerate of HTLC-transaction,
>> feerate estimation of any CPFP to bump it. I think that's kind of worthy to
>> do once we solved 3. and 4
>>
>> > 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.
>>
>> Yes we may encode all HTLC in some Taproot tree in the future. There are
>> some wrinkles but for a high-level theoretical construction see my post on
>> CoinPool.
>>
>> > 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)
>>
>> Likely a bit more of fee bikeshedding is something we have to do to make
>> LN secure... Switching fee from pre-committed ones to a single-party,
>> dynamic one.
>>
>> > Independently I think we should 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Olaoluwa Osuntokun]

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 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[ZmnSCPxj via Lightning-dev]

Good morning Jeremy,

> My understanding is that you can use the CTV deferral to also get independent 
> HTLC relative timelocks start points per output. This would help with this 
> sort of issue right?
>
> And you're correct that there's overhead of indirection, but it's not super 
> large (minimally complicated something like an extra 100 bytes per output, if 
> you were to have a flat array where each entry is a CTV output so that each 
> out gets its own clock).
>
> Essentially something like this:
>
> Chan
>  |
>  
>  |      |      |       |    |
>CTV(A) CTV(B) CTV(C)  CTV(D)  (Optional CPFP Anchor?)
>  |      |      |       | 
> 1 block  1 block 1 block  1 block
>  |      |      |   |
>     A   B  C   D
>
> Where A B C and D are all HTLCs.
>
> Now because of the one-hop indirection, A B C and D can all expand 
> independently. It's also possible for the Channel Operator to do something 
> like:
>
> Chan
>  |
>  ---
>  |      |      |      |    |
>CTV(A) CTV(B) CTV(C) CTV(D)  (Optional CPFP Anchor?)
>  |      |      |      |
> 1 block  1 block 1 block 10 blocks
>  |      |      |      |
>     A   B  C  D
>
> To make D have a further out resolution time to prevent the simultaneous-ness 
> issue (trees or a linear-chain rather than total fan-out can also be used but 
> I think it's a bit more confusing for a basic example).

The Lightning HTLCs use absolute timelocks, and the timelocks are pre-arranged 
by the original sender.
A forwarding node has to ensure that the outgoing HTLC timeout is respected, or 
else it could lose funds (by having the outgoing HTLC be claimed by outgoing 
peer hashlock and the incoming HTLC be calimed by the incoming peer timelock).

(We cannot use relative timelocks in the timelock branches of the HTLCs because 
we are coordinating possibly up to 20 different nodes, and do not want to leak 
the entire route to any of the intermediate nodes, so everyone has to use the 
same clock --- the absolute blockheight --- to measure time)

So, if my understanding of your above graph is correct, you are suggesting that 
HTLC D could have a relative timelock of 10 blocks instead of 1.

But all that means is that if the timelock of D is at height L, then the 
forwarder has to ensure that the commitment transaction appears onchain no 
later than height L - 10 (in practice I have to publish it at L - 11 so it 
propagates to miners who are building L - 10).
If not, the HTLC cannot be published at height L and the timelock cannot be 
enforced, risking fund loss.

This seems to *tighten* whatever leeway I might have bought by using CTV.
In current C-Lightning, for instance, for a timelock in my favor at height L, I 
have to broadcast the commitment transaction at time L - 1 so it goes into 
block L and I can claim it.
Thus, I have the option to publish from now up to L - 1.
With a further delay of 10 on the HTLC tx D, I now only have the option to 
publish from now up to L - 11, thus I have *less* leeway in when I can publish 
the commitment tx.

Basically the fund-security of the forwarding node is based on the absolute 
timelock of every HTLC it offers, so the timelock is an absolute bound on 
whatever techniques I might use to reduce fees.


> The benefit of trees is that I can do something like:
>
> Chan
>  |
>  
>  |      |      |      |          |
>CTV(A) CTV(B) CTV(C) CTV(400 HTLC)  (Optional CPFP Anchor?)
>  |      |      |      |                  |
> 1 block 1 block  1 block 10 blocks (Optional CPFP Anchor?)
>  |      |      |      |
>  |  |  |   / \
>     A   B  C  | . |
>
> Which makes it so that the low-value new HTLCs can be deprioritized fee wise. 
> So that the attack, which occurs during a fee spike, doesn't end up 
> *requiring* substantial fees to be added to the channel to support a burst of 
> HTLCS.

If the HTLCs have a timelock L, then I *need* to publish the HTLCs at timelock 
L or else the timelock cannot be enforced.

This means I need to publish the big `| . |` transaction with 400 HTLCs 
before timelock L, where L is `min (L) for all 400 HTLCs`.

The attacker can arrange to have the 400 low-value HTLCs have the same timelock 
L.
So even if the `| . |` is a tree of CTVs, I have to publish the entire tree 
at the same time so that the final HTLCs appear at timelock L and I can reclaim 
my funds.

If I do not publish, I run the risk that the total fund going to `CTV(400 
HTLC)` gets stolen from me by publication of the hashlock on the outgoing and 
publication of the timelock at the incoming.
Not publishing this due to fee spikes is basically trusting that the next peer 
is not going to steal the fund by hashlock branch.
And the next peer is an attacker 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Jeremy]

Hi ZmnSCPxj,

My understanding is that you can use the CTV deferral to also get
independent HTLC relative timelocks start points per output. This would
help with this sort of issue right?

And you're correct that there's overhead of indirection, but it's not super
large (minimally complicated something like an extra 100 bytes per output,
if you were to have a flat array where each entry is a CTV output so that
each out gets its own clock).

Essentially something like this:

Chan
 |
 -
 |   | | ||
CTV(A) CTV(B) CTV(C) CTV(D)  (Optional CPFP Anchor?)
 |   | | |
1 block1 block   1 block   1 block
 |   | | |
A  B   CD

Where A B C and D are all HTLCs.

Now because of the one-hop indirection, A B C and D can all expand
independently. It's also possible for the Channel Operator to do something
like:

Chan
 |
 -
 |   | | ||
CTV(A) CTV(B) CTV(C) CTV(D)  (Optional CPFP Anchor?)
 |   | | |
1 block1 block   1 block   10 blocks
 |   | | |
A  B   CD

To make D have a further out resolution time to prevent the
simultaneous-ness issue (trees or a linear-chain rather than total fan-out
can also be used but I think it's a bit more confusing for a basic
example). The benefit of trees is that I can do something like:


Chan
 |
 
 |   | | |  |
CTV(A) CTV(B) CTV(C) CTV(400 HTLC)  (Optional CPFP Anchor?)
 |   | | ||
1 block1 block   1 block   10 blocks  (Optional CPFP Anchor?)
 |   | |  |
 |   | | / \
A  B   C| . |

Which makes it so that the low-value new HTLCs can be deprioritized fee
wise. So that the attack, which occurs during a fee spike, doesn't end up
*requiring* substantial fees to be added to the channel to support a burst
of HTLCS.

--
@JeremyRubin 



On Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj  wrote:

> Good morning Jeremy,
>
> > I am not steeped enough in Lightning Protocol issues to get the full
> design space, but I'm fairly certain BIP-119 Congestion Control trees would
> help with this issue.
> >
> > You can bucket a tree by doing a histogram of HTLC size, so that all
> small HTLCs live in a common CTV subtree and don't interfere with higher
> value HTLCs. You can also play with sequencing to prevent those HTLCs from
> getting longchains in the mempool until they're above a certain value.
>
> If the attacker stops responding, then all HTLC rules need to be published
> onchain for enforcement of the HTLC rules.
> And that publication onchain is the problem: every HTLC published requires
> onchain space, which must be paid for.
>
> The most compact way to expose the HTLCs is as a flat array, i.e. outputs
> of a single transaction.
> Every tree structure is going to take up more space than a flat array.
>
> What CTV buys is to be able to defer *when* you reveal scripts, possibly
> to a later time when blockchain space is cheaper.
> But in case the victim owns the timelock branch of an outgoing HTLC, it is
> unsafe for the victim to defer: it has to enforce the locktime soon or it
> could end up losing both incoming and outgoing HTLC amounts.
> And to enforce the locktime it has to publish the HTLC.
>
> Now of course with CTV you could publish only the HTLC you have to enforce
> *now*, and keep the rest in an CTV output.
> The attacker can counter this by pushing 483 HTLCs with the same timelock
> at the victim, so that the victim has to publish all HTLCs simultaneously.
> And a flat array of outputs is cheaper than a tree.
>
> What *can* be done would be to bin by timelock rather than amount; tree
> leaves are a transaction that exposes all HTLCs with a particular timelock
> as a flat array of outputs, but different timelocks go to different tree
> branches.
> But the attacker can still do the same-timelock trick, and the tree
> structure is likely to take up more space in the end than just a non-treed
> flat array of outputs.
>
> Regards,
> ZmnSCPxj
>
>
> > --
> > @JeremyRubin
> >
> > On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard 
> wrote:
> >
> > > Hi Rene,
> > > Thanks for disclosing this vulnerability,
> > >
> > > I think this blackmail scenario holds but sadly there is a lower
> scenario.
> > >
> > > Both "Flood & Loot" and your blackmail attack rely on `update_fee`
> mechanism and unbounded commitment transaction size inflation. Though 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[ZmnSCPxj via Lightning-dev]

Good morning Jeremy,

> I am not steeped enough in Lightning Protocol issues to get the full design 
> space, but I'm fairly certain BIP-119 Congestion Control trees would help 
> with this issue.
>
> You can bucket a tree by doing a histogram of HTLC size, so that all small 
> HTLCs live in a common CTV subtree and don't interfere with higher value 
> HTLCs. You can also play with sequencing to prevent those HTLCs from getting 
> longchains in the mempool until they're above a certain value.

If the attacker stops responding, then all HTLC rules need to be published 
onchain for enforcement of the HTLC rules.
And that publication onchain is the problem: every HTLC published requires 
onchain space, which must be paid for.

The most compact way to expose the HTLCs is as a flat array, i.e. outputs of a 
single transaction.
Every tree structure is going to take up more space than a flat array.

What CTV buys is to be able to defer *when* you reveal scripts, possibly to a 
later time when blockchain space is cheaper.
But in case the victim owns the timelock branch of an outgoing HTLC, it is 
unsafe for the victim to defer: it has to enforce the locktime soon or it could 
end up losing both incoming and outgoing HTLC amounts.
And to enforce the locktime it has to publish the HTLC.

Now of course with CTV you could publish only the HTLC you have to enforce 
*now*, and keep the rest in an CTV output.
The attacker can counter this by pushing 483 HTLCs with the same timelock at 
the victim, so that the victim has to publish all HTLCs simultaneously.
And a flat array of outputs is cheaper than a tree.

What *can* be done would be to bin by timelock rather than amount; tree leaves 
are a transaction that exposes all HTLCs with a particular timelock as a flat 
array of outputs, but different timelocks go to different tree branches.
But the attacker can still do the same-timelock trick, and the tree structure 
is likely to take up more space in the end than just a non-treed flat array of 
outputs.

Regards,
ZmnSCPxj


> --
> @JeremyRubin
>
> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard  wrote:
>
> > Hi Rene,
> > Thanks for disclosing this vulnerability,
> >
> > I think this blackmail scenario holds but sadly there is a lower scenario.
> >
> > Both "Flood & Loot" and your blackmail attack rely on `update_fee` 
> > mechanism and unbounded commitment transaction size inflation. Though the 
> > first to provoke block congestion and yours to lockdown in-flight fees as 
> > funds hostage situation.
> >
> > > 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.
> >
> > As of today, yes I would recommend capping commitment size both for 
> > ensuring competitive propagation/block selection and limiting HTLC exposure.
> >
> > > 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.
> >
> > It's a bit more complex, carve-out output, even combined with anchor output 
> > support on the LN-side won't protect against different flavors of pinning. 
> > I invite you to go through logs of past 2 LN dev meetings.
> >
> > > 3. Don't overpay fees in commitment transactions. We can't foresee the 
> > > future anyway
> >
> > Once 2. is well-addressed we may deprecate `update_fee`.
> >
> > > 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.
> >
> > Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC 
> > economic value, feerate of its output, feerate of HTLC-transaction, feerate 
> > estimation of any CPFP to bump it. I think that's kind of worthy to do once 
> > we solved 3. and 4
> >
> > > 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.
> >
> > Yes we may encode all HTLC in some Taproot tree in the future. There are 
> > some wrinkles but for a high-level theoretical construction see my post on 
> > CoinPool.
> >
> > > 6. Split onchain fees differently (now the attacker would also lose fees 
> > > by conducting this attack) - No I don't 

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Jeremy]

I am not steeped enough in Lightning Protocol issues to get the full design
space, but I'm fairly certain BIP-119 Congestion Control trees would help
with this issue.

You can bucket a tree by doing a histogram of HTLC size, so that all small
HTLCs live in a common CTV subtree and don't interfere with higher value
HTLCs. You can also play with sequencing to prevent those HTLCs from
getting longchains in the mempool until they're above a certain value.
--
@JeremyRubin 



On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard 
wrote:

> Hi Rene,
>
> Thanks for disclosing this vulnerability,
>
> I think this blackmail scenario holds but sadly there is a lower scenario.
>
> Both "Flood & Loot" and your blackmail attack rely on `update_fee`
> mechanism and unbounded commitment transaction size inflation. Though the
> first to provoke block congestion and yours to lockdown in-flight fees as
> funds hostage situation.
>
> > 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.
>
> As of today, yes I would recommend capping commitment size both for
> ensuring competitive propagation/block selection and limiting HTLC exposure.
>
> > 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.
>
> It's a bit more complex, carve-out output, even combined with anchor
> output support on the LN-side won't protect against different flavors of
> pinning. I invite you to go through logs of past 2 LN dev meetings.
>
> > 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
>
> Once 2. is well-addressed we may deprecate `update_fee`.
>
> > 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.
>
> Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
> economic value, feerate of its output, feerate of HTLC-transaction, feerate
> estimation of any CPFP to bump it. I think that's kind of worthy to do once
> we solved 3. and 4
>
> > 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.
>
> Yes we may encode all HTLC in some Taproot tree in the future. There are
> some wrinkles but for a high-level theoretical construction see my post on
> CoinPool.
>
> > 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)
>
> Likely a bit more of fee bikeshedding is something we have to do to make
> LN secure... Switching fee from pre-committed ones to a single-party,
> dynamic one.
>
> > 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.
>
> I 100% agree, that's exactly
> https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
> your feedback :)
>
> Cheers,
>
> Antoine
>
> Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> a écrit :
>
>>
>> Good morning all,
>>
>> >
>> > Fee futures could help against this.
>> > I remember writing about this some time ago but cannot find where (not
>> sure if it was in lightning-dev or bitcoin-dev).
>>
>> `harding` found it:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>>
>> Regards,
>> ZmnSCPxj
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[Antoine Riard]

Hi Rene,

Thanks for disclosing this vulnerability,

I think this blackmail scenario holds but sadly there is a lower scenario.

Both "Flood & Loot" and your blackmail attack rely on `update_fee`
mechanism and unbounded commitment transaction size inflation. Though the
first to provoke block congestion and yours to lockdown in-flight fees as
funds hostage situation.

> 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.

As of today, yes I would recommend capping commitment size both for
ensuring competitive propagation/block selection and limiting HTLC exposure.

> 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.

It's a bit more complex, carve-out output, even combined with anchor output
support on the LN-side won't protect against different flavors of pinning.
I invite you to go through logs of past 2 LN dev meetings.

> 3. Don't overpay fees in commitment transactions. We can't foresee the
future anyway

Once 2. is well-addressed we may deprecate `update_fee`.

> 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.

Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
economic value, feerate of its output, feerate of HTLC-transaction, feerate
estimation of any CPFP to bump it. I think that's kind of worthy to do once
we solved 3. and 4

> 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.

Yes we may encode all HTLC in some Taproot tree in the future. There are
some wrinkles but for a high-level theoretical construction see my post on
CoinPool.

> 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)

Likely a bit more of fee bikeshedding is something we have to do to make LN
secure... Switching fee from pre-committed ones to a single-party, dynamic
one.

> 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.

I 100% agree, that's exactly
https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
your feedback :)

Cheers,

Antoine

Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :

>
> Good morning all,
>
> >
> > Fee futures could help against this.
> > I remember writing about this some time ago but cannot find where (not
> sure if it was in lightning-dev or bitcoin-dev).
>
> `harding` found it:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[ZmnSCPxj via Lightning-dev]

Good morning all,

>
> Fee futures could help against this.
> I remember writing about this some time ago but cannot find where (not sure 
> if it was in lightning-dev or bitcoin-dev).

`harding` found it: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[ZmnSCPxj via Lightning-dev]

Good morning Rene,

Thank you for the report, this is good.

> 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

Fee futures could help against this.
I remember writing about this some time ago but cannot find where (not sure if 
it was in lightning-dev or bitcoin-dev).

As a rough sketch, a client contacts a fee insurance service.
For a fixed fee, the client arranges such that the fee insurance service pays 
for fees in case of a condition where feerates increase.

This is done by arranging a 2-of-2 output spending the insurance premium 
payment and some maximum fee the insurance service provides.
Initially sign an `nLockTime`d transaction that represents the end of the 
insurance service contract.
Then at each commitment tx, sign a variety of feerates spending the CPFP 
carve-out and the insurance 2-of-2, utilizing the insurnace funds for doing the 
CPFP.

> 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.

Seems a reasonable heuristic.

> 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.

This seems impossible; once you add the points of two unrelated PTLCs, in order 
to separate them again once you learn the aggregate scalar, you need to learn 
the scalar of one separately from the scalar of the other, but the aggregate 
PTLC does not impose the requirement from the receiver to reveal each of the 
scalars separately.

You *could* require multiple signatures instead of a single signature, in which 
case each completed signature can reveal a separate scalar behind a point.
Revealing the points and the signatures is 96 bytes, plus a few more bytes for 
opcodes, divided by 4 because witness, so about equivalent to 24 block space 
per PTLC you merge.

This cost would be paid by the receiver of the HTLC.
The timelock branch can be made not to have to reveal any of the points, by 
Taproot-signing the timelock branch, or using a separate tapscript (at the cost 
of additional 32 witness bytes to select branches, if my taproot understanding 
holds).

--

Combining timelocks is also bad.
If you combine two PTLCs with different timelocks, which do you choose, the 
larger or the smaller?

* If you choose the larger, the sender of the PTLCs could have a larger 
outgoing timelock than the its incoming PTLC, then possibly might lose money 
when the incoming PTLC times out but the outgoing timelock is not yet timed out 
and can still be claimed by scalar revelation.
* If you choose the smaller, then the next hop might not have enough block time 
to deliver the payment, in which case later hops on the route will fail more 
often (possibly an acceptable tradeoff? c-lightning does shadow routing which 
overallocates timelock anyway...).
* If you cannot combine different timelocks, the attacker can arrange PTLCs 
with timelocks from now+2 to now+484 to mount the attack.

--

You could try aggregating using `OP_CHECKTEMPLATEVERIFY`, or equivalently with 
a pre-signed transaction, but that just moves the revelation cost to the 
receiver of the PTLC, which multiple signatures above does just as well.
It does have the advantage of retaining the timelocks.


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

[René Pickhardt via Lightning-dev]

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=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