Date: Wed, 3 Jun 2020 19:20:09 +0300
From: Gleb Naumenko <naumenko.gs@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark>
In-Reply-To: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
References: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ed7cdbe_2443a858_1a3"
Subject: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Precedence: list

--5ed7cdbe_2443a858_1a3
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi=21 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:=C2=A0https://discrete-blog.github.io/time-dilation/=

There=E2=80=99s also a paper we wrote:=C2=A0https://arxiv.org/abs/2006.01=
418


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

Now, let me share the intro from the post with you (which is really a sum=
mary of the work), since it=E2=80=99s 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 tr=
emendous opportunities in terms of scalability, confidentiality, and func=
tionality, at a cost of new security assumptions.

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

More specifically, we explored how peer-to-peer layer attacks can help wi=
th breaking the assumption above. Per time-dilation attacks, an attacker =
controls the victim=E2=80=99s access to the Bitcoin network (hard, but no=
t impossible) and delays block delivery to the victim. After that, the at=
tacker exploits that the victim can=E2=80=99t access recent blocks in a t=
imely 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=E2=80=99s channels, and at the same time comm=
its 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 explo=
re the broad scope of countermeasures, which may significantly increase t=
he 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 robus=
t to Eclipse attacks, but the attacks are still possible as recent resear=
ch suggests.
3. Eclipse attacks enable stealing funds via time-dilation.
4. Time-dilation attacks can=E2=80=99t be mitigated with just observing s=
low block arrival, so there is no simple solution to (3).
5. Thus, time-dilation is a practical way to steal funds from eclipsed us=
ers. Neither it requires hashrate nor targets merchants only. Light clien=
t users are a good target because they are easy to attack. =46ull node us=
ers are a good target because they are often used by major hubs (or servi=
ce providers), and stealing their aggregate liquidiy might justify the hi=
gh attack cost.
6. Strong anti-Eclipse measures is the key solution. WatchTowers are cool=
 too.


Best,

Gleb Naumenko and Antoine Riard

--5ed7cdbe_2443a858_1a3
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi=21 I and Antoine Riard explored time-dilation at=
tacks on Lightning.<br />
<br />
We have a blogpost, which is probably too long to include in the email in=
 full.<br />
You can read it here:&=23160;<a href=3D=22https://discrete-blog.github.io=
/time-dilation/=22 target=3D=22=5Fblank=22>https://discrete-blog.github.i=
o/time-dilation/</a><br />
There=E2=80=99s also a paper we wrote:&=23160;<a href=3D=22https://arxiv.=
org/abs/2006.01418=22 target=3D=22=5Fblank=22>https://arxiv.org/abs/2006.=
01418</a><br />
<br />
<br />
We believe this work should be interesting for anyone curious/excited abo=
ut LN or other second-layer protocols in Bitcoin. We are very interested =
in your opinions=21<br />
<br />
Now, let me share the intro from the post with you (which is really a sum=
mary of the work), since it=E2=80=99s about the right size for a mailing =
list post. Hopefully, it would motivate you to read further.<br />
<br />
Protocols on top of the Bitcoin base layer are really cool. They offer tr=
emendous opportunities in terms of scalability, confidentiality, and func=
tionality, at a cost of new security assumptions.<br />
<br />
We all know payment channels have to be monitored, otherwise, the funds c=
an be stolen. That sounds too abstract though. We decided to study what a=
n attacker actually has to do to steal funds from LN users.<br />
<br />
More specifically, we explored how peer-to-peer layer attacks can help wi=
th breaking the assumption above. Per time-dilation attacks, an attacker =
controls the victim=E2=80=99s access to the Bitcoin network (hard, but no=
t impossible) and delays block delivery to the victim. After that, the at=
tacker exploits that the victim can=E2=80=99t access recent blocks in a t=
imely manner. In some cases, it is enough to isolate the victim only for =
two hours.<br />
<br />
Then the attacker makes a couple (totally legit) actions on the Lightning=
 Network towards the victim=E2=80=99s channels, and at the same time comm=
its 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.<br />
<br />
We demonstrate three different ways the attacker can steal funds from the=
 victim, and discuss the feasibility/cost of these attacks. We also explo=
re the broad scope of countermeasures, which may significantly increase t=
he attack cost.<br />
<br />
In short, the takeaways from our work are:</div>
<ol type=3D=221=22>
<li>Many Lightning users (those with Bitcoin light clients) are currently=
 vulnerable to Eclipse attacks.</li>
<li>Those Lightning users which run Bitcoin Core full nodes are more robu=
st to Eclipse attacks, but the attacks are still possible as recent resea=
rch suggests.</li>
<li>Eclipse attacks enable stealing funds via time-dilation.</li>
<li>Time-dilation attacks can=E2=80=99t be mitigated with just observing =
slow block arrival, so there is no simple solution to (3).</li>
<li>Thus, time-dilation is a practical way to steal funds from eclipsed u=
sers. Neither it requires hashrate nor targets merchants only. Light clie=
nt users are a good target because they are easy to attack. =46ull node u=
sers are a good target because they are often used by major hubs (or serv=
ice providers), and stealing their aggregate liquidiy might justify the h=
igh attack cost.</li>
<li>Strong anti-Eclipse measures is the key solution. WatchTowers are coo=
l too.</li>
</ol>
<div dir=3D=22auto=22><br />
Best,</div>
</div>
<div name=3D=22messageSignatureSection=22><br />
<div dir=3D=22auto=22>Gleb Naumenko and Antoine Riard</div>
</div>
</body>
</html>

--5ed7cdbe_2443a858_1a3--