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 hav

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 end

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 i

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 th