From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BB37FC016E for ; 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 ; 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 ; 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 ; Wed, 3 Jun 2020 16:20:19 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id d7so1678563lfi.12 for ; 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 (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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi=21 I and Antoine Riard explored time-dilation at= tacks on Lightning.

We have a blogpost, which is probably too long to include in the email in= full.
You can read it here:&=23160;https://discrete-blog.github.i= o/time-dilation/
There=E2=80=99s also a paper we wrote:&=23160;https://arxiv.org/abs/2006.= 01418


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 robu= st to Eclipse attacks, but the attacks are still possible as recent resea= rch suggests.
  3. Eclipse attacks enable stealing funds via time-dilation.
  4. Time-dilation attacks can=E2=80=99t 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 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.
  6. Strong anti-Eclipse measures is the key solution. WatchTowers are coo= l too.

Best,

Gleb Naumenko and Antoine Riard
--5ed7cdbe_2443a858_1a3--