[bitcoin-dev] Time-dilation Attacks on the Lightning Network

From: Gleb Naumenko <naumenko.gs@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Date: Wed, 3 Jun 2020 19:20:09 +0300	[thread overview]
Message-ID: <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark> (raw)
In-Reply-To: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>

[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]

Hi! I and Antoine Riard explored time-dilation attacks on Lightning.

We have a blogpost, which is probably too long to include in the email in full.
You can read it here: https://discrete-blog.github.io/time-dilation/
There’s also a paper we wrote: https://arxiv.org/abs/2006.01418

We believe this work should be interesting for anyone curious/excited about LN or other second-layer protocols in Bitcoin. We are very interested in your opinions!

Now, let me share the intro from the post with you (which is really a summary of the work), since it’s about the right size for a mailing list post. Hopefully, it would motivate you to read further.

Protocols on top of the Bitcoin base layer are really cool. They offer tremendous opportunities in terms of scalability, confidentiality, and functionality, at a cost of new security assumptions.

We all know payment channels have to be monitored, otherwise, the funds can be stolen. That sounds too abstract though. We decided to study what an attacker actually has to do to steal funds from LN users.

More specifically, we explored how peer-to-peer layer attacks can help with breaking the assumption above. Per time-dilation attacks, an attacker controls the victim’s access to the Bitcoin network (hard, but not impossible) and delays block delivery to the victim. After that, the attacker exploits that the victim can’t access recent blocks in a timely manner. In some cases, it is enough to isolate the victim only for two hours.

Then the attacker makes a couple (totally legit) actions on the Lightning Network towards the victim’s channels, and at the same time commits a different state instead. Since the victim is behind in terms of the latest blockchain tip, they cannot detect this and react as required by the protocol.

We demonstrate three different ways the attacker can steal funds from the victim, and discuss the feasibility/cost of these attacks. We also explore the broad scope of countermeasures, which may significantly increase the attack cost.

In short, the takeaways from our work are:

1. Many Lightning users (those with Bitcoin light clients) are currently vulnerable to Eclipse attacks.
2. Those Lightning users which run Bitcoin Core full nodes are more robust to Eclipse attacks, but the attacks are still possible as recent research suggests.
3. Eclipse attacks enable stealing funds via time-dilation.
4. Time-dilation attacks can’t be mitigated with just observing slow block arrival, so there is no simple solution to (3).
5. Thus, time-dilation is a practical way to steal funds from eclipsed users. Neither it requires hashrate nor targets merchants only. Light client users are a good target because they are easy to attack. Full node users are a good target because they are often used by major hubs (or service providers), and stealing their aggregate liquidiy might justify the high attack cost.
6. Strong anti-Eclipse measures is the key solution. WatchTowers are cool too.

Best,

Gleb Naumenko and Antoine Riard

[-- Attachment #2: Type: text/html, Size: 3656 bytes --]