t-bast
4 years ago
1 changed files with 227 additions and 0 deletions
@ -0,0 +1,227 @@ |
|||
# Pinning Attacks |
|||
|
|||
This article summarizes the discussions about pinning attacks (discussed |
|||
[here](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html) and |
|||
[here](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html)) and ideas |
|||
that have been proposed to mitigate this class of attacks. |
|||
|
|||
## Table of Contents |
|||
|
|||
* [Threat Model](#threat-model) |
|||
* [Attacks on Lightning](#attacks-on-lightning) |
|||
* [Attacking individual HTLCs](#attacking-individual-htlcs) |
|||
* [Attacking commitment transactions](#attacking-commitment-transactions) |
|||
* [Anchor outputs](#anchor-outputs) |
|||
* [Mitigations](#mitigations) |
|||
* [Update fee must stay](#update-fee-must-stay) |
|||
* [Spamming the bitcoin network](#spamming-the-bitcoin-network) |
|||
* [Pay for preimage](#pay-for-preimage) |
|||
* [Out of band package relay](#out-of-band-package-relay) |
|||
* [Insert your ideas here](#insert-your-ideas-here) |
|||
|
|||
## Threat Model |
|||
|
|||
In Bitcoin, "There Ain't No Such Thing As A Global Mempool" (TANSTAAGM - credits to Z-man). |
|||
Bitcoin will not try to enforce mempool convergence nor try to resolve mempool [split-brains](https://en.wikipedia.org/wiki/Split-brain_(computing)). |
|||
These split-brain occurences are slowly and partially resolved by getting some of the mempool |
|||
transactions confirmed in blocks: that is and will always be the only consensus-enforced data |
|||
structure available. |
|||
|
|||
A clever and well-funded attacker is able to manipulate mempools and create arbitrary split-brains, |
|||
that last an arbitrary amount of time. |
|||
We must work under the assumption that such attackers are able to accurately split the network's |
|||
mempools, ensuring for example that N% of miners' mempool contain a transaction txA while the rest |
|||
of the network's mempools all contain a conflicting transaction txB. |
|||
|
|||
Lightning, as well as other off-chain contracts, must ensure that users don't suffer a loss of |
|||
funds from such mempool partitions. |
|||
|
|||
## Attacks on Lightning |
|||
|
|||
In this threat model, there are two types of attacks that can be carried out: attacks on individual |
|||
HTLC transactions and attacks on commitment transactions. The goal of both of these attacks is to |
|||
steal pending HTLCs (HTLC outputs in the broadcast commitment transaction), exploiting a routing |
|||
node by timing out HTLCs upstream while collecting them on-chain downstream. |
|||
|
|||
```ascii |
|||
Attacker -----------------------> Victim ----------------------------> Attacker |
|||
(upstream) ^ ^ (downstream) |
|||
| | |
|||
| | |
|||
+---------------------------+ +------------------------+ |
|||
| HTLCs timed out off-chain | | HTLCs claimed on-chain | |
|||
+---------------------------+ +------------------------+ |
|||
|
|||
``` |
|||
|
|||
Note that none of these attacks are able to steal participants' main outputs, only HTLCs. |
|||
A general mitigation is thus to limit the number of pending HTLCs in the commitment transaction, |
|||
and limit the amount pending across those HTLCs. Existing Lightning implementations already offer |
|||
ways to configure these limits. |
|||
|
|||
These attacks cannot be used to steal from wallets either, since they don't relay payments. |
|||
|
|||
### Attacking individual HTLCs |
|||
|
|||
This attack works at the HTLC transaction level. The attacker creates the following mempool |
|||
split-brain: |
|||
|
|||
* all miners have a success transaction in their mempool, revealing the preimage to claim the HTLC |
|||
* the rest of the network has a timeout transaction in their mempool |
|||
|
|||
The attacker ensures the preimage transaction has a low enough feerate to be kept in the mempool |
|||
without confirming before the upstream channel can timeout them off-chain. |
|||
|
|||
The attacker can also ensure that the transaction in the miners' mempool cannot be replaced, by |
|||
attaching a long enough chain of child transactions (BIP 125 rule 5). |
|||
|
|||
This can be done: |
|||
|
|||
* With the current commitment format (no anchor outputs), by forcing the victim to broadcast their |
|||
commitment since the htlc preimage branch has no restriction on how it's spent. |
|||
* With anchor outputs, either with the same solution as above, or by adding outputs to the |
|||
HTLC-success transaction (thanks to `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY`). |
|||
|
|||
There are two ways the victim can defend against this attack: |
|||
|
|||
* learn the preimage before the upstream HTLC times out |
|||
* or get his timeout transaction confirmed |
|||
|
|||
### Attacking commitment transactions |
|||
|
|||
This attack works at the commitment transaction level, and thus impacts all HTLCs outputs in that |
|||
transaction. The attacker creates the following mempool split-brain: |
|||
|
|||
* all miners have one version of the commitment transaction |
|||
* the rest of the network has another version of the commitment transaction |
|||
|
|||
Note that there are variants of this attack where the network can be arbitrarily split into N |
|||
clusters, each with a different version of the commitment transaction. At a high level, this |
|||
achieves the same result and mitigations should address this whole class of attacks. |
|||
|
|||
The attacker ensures the commitment transaction in the miners' mempools has a low enough feerate to |
|||
be kept without confirming before the upstream channel can timeout HTLCs off-chain. |
|||
|
|||
The attacker can also ensure that the transaction in the miners' mempool cannot be replaced: |
|||
|
|||
* With the current commitment format (no anchor outputs), this can be done by using a commitment |
|||
transaction with a feerate at least equal to the victim's latest commitment, since the victim |
|||
cannot bump the fees of his own commitment transaction. |
|||
* With anchor outputs, this can be done by attaching a long enough chain of child transactions via |
|||
the attacker's anchor (BIP 125 rule 5). |
|||
|
|||
The only way the victim can defend against this attack is by somehow getting a commitment |
|||
transaction confirmed. It doesn't matter which one is confirmed: if it's a revoked commitment, the |
|||
victim can claim all the channels funds (payback time, b*tches), if it's the latest commitment the |
|||
victim has to claim or timeout HTLCs afterwards. |
|||
|
|||
## Anchor outputs |
|||
|
|||
The [anchor outputs proposal](https://github.com/lightningnetwork/lightning-rfc/pull/688) doesn't |
|||
fix this class of attacks, but it doesn't make the situation worse. See the two previous sections |
|||
for details. |
|||
|
|||
It solves another class of attacks, so I believe it makes sense to implement today (regardless of |
|||
potential future commitment changes once bitcoin offers some kind of package relay). |
|||
|
|||
## Mitigations |
|||
|
|||
First of all, let's clarify that CPFP/carve-out cannot save us in that case. Without package relay, |
|||
CPFP will not help our valid transaction propagate all the way to miners' mempools. And even if you |
|||
knew what transaction is in the miners' mempools somehow and wanted to use CPFP/carve-out to get |
|||
that transaction to confirm (which unblocks the situation) you cannot propagate your carve-out to |
|||
miners because your area of the network doesn't have the transaction from which you're carving out |
|||
in their mempools, so they won't relay anything. |
|||
|
|||
A long-term mitigation is to deploy some form of package relay on the bitcoin network that would |
|||
allow us to send a package "our valid tx + a child that bumps fee" that would always be able to |
|||
replace the attacker's pinned transaction (as long as our package pays enough fees). This is not |
|||
an easy task and it will take time, so we will now explore some short-term mitigations. |
|||
|
|||
Disclaimer: most of these (clever) ideas are not mine. I'm merely trying to summarize them to help |
|||
the discussion move forward. |
|||
|
|||
### Update fee must stay |
|||
|
|||
The current `update_fee` mechanism is clearly imperfect; it's impossible to predict the future. |
|||
But it does raise the bar for the commitment transaction pinning attack. If you ensure commitment |
|||
transactions you sign always pay a high fee, the attacker can only keep it pinned in miners' |
|||
mempools during high mempool congestion. If your `cltv_expiry_delta` is high enough, the attacker's |
|||
commitment transaction is likely to get confirmed, which thwarts the attack (especially if it's a |
|||
revoked commitment transaction that confirms). |
|||
|
|||
This doesn't mitigate the attack on HTLC preimage transactions though, because those have a feerate |
|||
unilaterally set by the attacker. |
|||
|
|||
### Spamming the bitcoin network |
|||
|
|||
Since the root of the issue is that we're missing information that some mempools have, the most |
|||
obvious solution is to connect to everyone available (ie every bitcoin node that accepts incoming |
|||
connections). It allows a node to discover conflicting transactions and either learn a preimage |
|||
or figure out what CPFP transaction it needs to send to speed up confirmation of a pinned |
|||
commitment transaction. |
|||
|
|||
Obviously this solution doesn't scale and may potentially not work; you have no guarantee that you |
|||
will be able to connect to enough nodes to probe mempools quickly enough (before upstream HTLCs |
|||
timeout). |
|||
|
|||
NB: this solution would also require a small change to `bitcoind`. LN nodes will need their |
|||
`bitcoind` to send them conflicting transactions that match a given format. When the LN node |
|||
receives such transactions, it can then act on them (extract preimage / commitment transaction). |
|||
|
|||
### Pay for preimage |
|||
|
|||
When we detect that our HTLC-timeout doesn't confirm in time, we can incentivize random nodes to |
|||
discover and share preimages by giving them a reward. |
|||
|
|||
This can come into free forms: |
|||
|
|||
* Broadcast pay-for-preimage transactions on-chain hoping they'll be claimed and you learn the |
|||
preimage in a block (`OP_SHA256 <hash_whose_preimage_bob_wants> OP_EQUAL`) |
|||
* Send probe HTLCs off-chain to random nodes; if these nodes know the preimage, they will claim |
|||
the HTLC even though they didn't create a matching invoice |
|||
* Rely on altruistic off-chain gossip of discovered preimages (we can rate-limit that gossip based |
|||
on the channel capacity our peer opened to us to avoid making this a DoS vector) |
|||
|
|||
These solutions all assume that nodes watch for mempool conflicts and analyze the conflicting |
|||
transactions to discover preimages (see previous section). These solutions only mitigate the attack |
|||
on individual HTLCs, not the one on commitment transactions. |
|||
|
|||
### Out of band package relay |
|||
|
|||
Another mitigation that could work for both attacks is to implement a limited package relay outside |
|||
of the bitcoin p2p relay. If (some) miners pick up these packages and manually (to be defined) |
|||
replace the conflicting transactions with the high-fee package received, that allows the honest |
|||
participant to get his transactions confirmed in time. As long as the fees are higher, miners have |
|||
an economic incentive to select these transactions. |
|||
|
|||
There are many out-of-band medium that can be used to propagate these packages, for example: |
|||
|
|||
* Using LN gossip (where we can rate-limit based on our peer's channel capacity). This assumes that |
|||
(some) miners will run a lightning node and receive that gossip. |
|||
* Using centralized APIs that miners would connect to over Tor. Lightning nodes with many funds at |
|||
risk can expose web servers that serve these high-fee packages when they need to broadcast them. |
|||
Miners could regularly poll these servers and pick transactions they like. |
|||
* Using publicly advertised bitcoin nodes that miners could connect to. The drawback is that it |
|||
attracts DoS attacks (same for the centralized APIs). |
|||
|
|||
This would require a few changes on Bitcoin Core. There is currently no RPC that lets the user |
|||
evict transactions from the mempool (and replace them with a different package); this could be |
|||
useful addition. Bitcoin Core could also provide a whitelist-only flag that would let miners |
|||
blindly accept conflicting transactions from chosen nodes (this assumes the miners trust these |
|||
nodes). |
|||
|
|||
### Insert your ideas here |
|||
|
|||
<insert your own ideas here> |
|||
|
|||
## Resources |
|||
|
|||
Thanks to David Harding, Matt Corallo, Antoine Riard and ZmnSCPxj for their patience, their |
|||
explanations and lengthy discussions and brainstorms! |
|||
|
|||
The following links may be useful to dig further: |
|||
|
|||
* [Opt-in RBF](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) |
|||
* [OG RBF pinning thread](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html) |
|||
* [Summary RBF pinning thread](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html) |
Loading…
Reference in new issue