Protect against `channel_announcement`s from channels that are already spent

[t-bast]

In #2936, we changed WatchExternalChannelSpent to be a WatchSpent instead of a WatchSpentBasic. One of the consequences is that whenever we receive a channel_announcement, we will call checkSpent:

eclair/eclair-core/src/main/scala/fr/acinq/eclair/blockchain/bitcoind/ZmqWatcher.scala

Line 378 in 27ba60f

private def checkSpent(w: WatchSpent[_ <: WatchSpentTriggered]): Future[Unit] = {

If the announcement is from a utxo that has been spent a long time ago, we go through client.lookForSpendingTx which iterates over blocks and is very inefficient. It's important to go through this process for our own channels, but for external channels this can be used as a DoS vector.

I'm not sure what exactly we should do: if we don't look into the blockchain, we won't find the spending tx and thus cannot wait 12 blocks before removing the channel. But if we look into the blockchain, that's expensive and can be abused...

[DerEwige]

What if we do not completely forget about closed channels?
We could store the closing transaction and SCID in a table.

Historically there have been around 1 million (public) lightning channels since inception.
Even if we stored all of them including closing transaction, that would not take up that much space.

But realistically, we only need to store the information for channels that get announced to us.
So when ever eclair forgets about a channel after 12 blocks, an entry would be made into that table.
When someone announces a long dead channel to us and we looked up that transaction in the block chain, save it into that table.

Check that table first when we get an unknown channel announced and verify the closing tx.

If a channel has not been announced to us for 30 days, purge it from the table. (probably need a “last_seen” field in the DB for that)

This way the table would stay reasonably small and we would only need to lookup a closing transaction at most once every 30 days in the worst case.

[t-bast]

Check that table first when we get an unknown channel announced and verify the closing tx.

That doesn't help with the issue I'm describing, since we wouldn't find an entry in that table?

[DerEwige]

Maybe I misunderstood the problem.
Let me rephrase it in my own words to see if I got it.

Eclair learns about a previously unknown channel.
Eclair verifies the opening TX.
Eclair checks if there is already a closing TX.
(this is the expensive part, especially if it is an old channel, that has been open for a long time)
Eclair finds the closing TX and removes/purges the channel again.

I thought the main problem is, that an attacker can send us the same channel over and over again.
We would do the same work every time.

I do not think we can prevent the work from being done the first time.
But we can create a tombstone for the channel in a cemetery instead of completely removing/purging it.
We can then check the cemetery before going to the blockchain.

So an attacker could only create load once per channel instead of repeatedly generate load with the same channel.

[t-bast]

I thought the main problem is, that an attacker can send us the same channel over and over again.
We would do the same work every time.

No, the issue isn't really with sending the same one over and over again, but sending us any 2-of-2 utxo that was spent a long time ago.

I do not think we can prevent the work from being done the first time.

That's the subtlety: we actually don't necessarily need to do all the work. There's a big difference in terms of performance between checking whether an output has been spent and finding the spending tx. In those cases, we most likely don't care about the spending tx itself, we can ignore the announcement/forget the channel if it was spent more than 12 blocks ago. But right now we'll iterate over much more of the blockchain than that (in eclair.conf, we have max-channel-spent-rescan-blocks = 720 by default) which is costly.

We can probably simply restrict that to 12 blocks in the case of WatchExternalChannelSpent.

[remyers]

If we receive a channel_announcement for a channel with a funding tx that is already spent (potentially long ago), then the channel will not be added to the graph (and will be removed if it does exist). This happens in handleChannelValidationResponse. We only track funding outputs with WatchExternalChannelSpent if they are first validated as unspent and we do not use client.lookForSpendingTx for spent txs during validation.

Only after validation do we monitor the funding tx with WatchExternalChannelSpent, and call client.lookForSpendingTx if the funding output is spent. In most cases our node should detect the spend while it's still in the mempool, but otherwise we should find it without searching back very many blocks.

When the Router starts up, some reloaded channels could have been spent while our node was down. Each spent channel would trigger client.lookForSpendingTx, but this isn't something that could be actively exploited.

[t-bast]

Nice, very good catch, I hadn't noticed that! You're right, thanks to that first check we're already safe, nothing more needs to be done, that's great 👍