path: root/53/abbce58426a87e311279b09a1c45dccfa90346

Return-Path: <naumenko.gs@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BB37FC016E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jun 2020 16:20:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id AA82F84693
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jun 2020 16:20:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F4JlhzejEHHh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jun 2020 16:20:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com
 [209.85.167.41])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 6FD8486C41
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jun 2020 16:20:19 +0000 (UTC)
Received: by mail-lf1-f41.google.com with SMTP id d7so1678563lfi.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 03 Jun 2020 09:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=date:from:to:message-id:in-reply-to:references:subject:mime-version;
 bh=8/R94ps0ZVRYFbeMylGnCsoq0pL31GX+lzx2v/YURtc=;
 b=Su0ECYbCwwZeWE03Rpt26dLMFPUuC5nys7M+QsYiPxX5ep2sLNVJAr4I8SFcUrxSnr
 CX/80dvTjtWhBYDZmX3V6/QctoPcYjSaAygvM0iW1coyizFedIfqz1x3aJQlkTwOlE+U
 +s2ATOnY75CTtdb4nIynTwi3gkzVgyiC3K37LtBPPAXTqvb03yDK1WPwskIcSAfavj8k
 G1YHtWzvVj7Nk6oL73JM2C78xT54jv3wAh4LqADqnH+h/sspRB1ud5CF3XpryCgy4KoP
 BFuYj2ua79AAXhxABc8kfq6HAb0O9+F7KAoxgFTjba7XSYke/LRzkK6pRYVdzYDmHr9g
 f4MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:message-id:in-reply-to:references
 :subject:mime-version;
 bh=8/R94ps0ZVRYFbeMylGnCsoq0pL31GX+lzx2v/YURtc=;
 b=GfZLe5u/UAaVv/Z+PA4maihKP0X0eKcJGkBJSW4wgtvWi3PppBTTMdtVeqk1b5bTUP
 NC7k2DK4q5bUPBK3RaByy+mK+DjZQZU/GRPVFvfcEgVoJHnkELZF9iokuBQDXJV8DGlZ
 SU39zdTziQVoppumTg7fHHsz2krfXFKYxKBasCknfBTtlQ89+Nnwp28apq0gT0RDppnY
 Gk9T071ftweHzqWPUBcMv1JTnQO3jGVpyE1c9+sqST8jW9sOKVWWbBUNFV0/JZo0AobK
 EaPLUprc2XLc2NThUphzw/F+cNvQblcUSD4AYNYb/x5t3AOE8WuqfyNxuYn41jUC4mrb
 iExw==
X-Gm-Message-State: AOAM533Ptickiq84vzQ5UFftqDZuHys1om7WPVmF/KWznIH4oegRPiCZ
 3KQeC3CYcCcOs/3/xJ7AQOM9FNldesE5aA==
X-Google-Smtp-Source: ABdhPJwprU0yaDjrq7x89ANeoYSmzVSu4+Zz/ujpz5Uf5CYfPJHkabUq8ugD/zG4MgERFOTPREBkUQ==
X-Received: by 2002:a19:2250:: with SMTP id i77mr141783lfi.133.1591201217151; 
 Wed, 03 Jun 2020 09:20:17 -0700 (PDT)
Received: from [192.168.0.147] ([159.224.16.138])
 by smtp.gmail.com with ESMTPSA id w20sm585357ljo.68.2020.06.03.09.20.15
 for <bitcoin-dev@lists.linuxfoundation.org>
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 03 Jun 2020 09:20:15 -0700 (PDT)
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>
X-Readdle-Message-ID: 9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ed7cdbe_2443a858_1a3"
X-Mailman-Approved-At: Wed, 03 Jun 2020 16:44:24 +0000
Subject: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 16:20:21 -0000

--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--