path: root/44/f3e8bc1fa7439d4aaf39441c70956e95e361af

Return-Path: <antoine.riard@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7AB33C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  7 Jun 2020 22:32:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 765A98586A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  7 Jun 2020 22:32:07 +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 vGpCmcU3pS9K
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  7 Jun 2020 22:32:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com
 [209.85.210.171])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 40452855CE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  7 Jun 2020 22:32:06 +0000 (UTC)
Received: by mail-pf1-f171.google.com with SMTP id b5so7665570pfp.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 07 Jun 2020 15:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=V09OcL17nC4tun4pg7rQncfCCto69sDkjZjLwSRf340=;
 b=hAR9qqeZU8P+HMEA4+uugCcO9mN6uSYsr+zN+6cE0cc8jNXDAMhMoNC327mDBTcseY
 1G3rDlR+JYOKzwrgxnPius/jxDP3CenE3P2Ys3nW6s8b0U3Tqx2p+fafaYky0ROrpyWb
 jO79rUFktzrbWdT9PR5/zcOvW9JtENt0wDSqlbOdwvicOcxfbJAriigub/bzsodfg0CH
 R3Zo6T4m2MvI4PARSvNbQzhQ/4NoGVRlnUSmPccRVFSuqNe+l7qVIG1vhU07qhvvgAlW
 ibhIFvPmYN2twMZjfP0pU/1Xrr87MCAwPqCYLR7UglYtETQM3ISZf6idMyrkv+8MMw1X
 3Sag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=V09OcL17nC4tun4pg7rQncfCCto69sDkjZjLwSRf340=;
 b=GpU1EJKrsIrApNKCUpzAC1SHEoGWcTAuV/SyTQuXNAHraD0hA9Mkl49RiToZsbArMj
 h6wb2s3SQ2nNMu/k5oLuQzs6KOCMP1P7YxVrBlXwad5fCNNr62c94+4t+8PpaxGPfEpd
 jJVTWOmv84fJaFfLbqltAvxOjSK1IixsWhzK3vcJfYzygss1XoDlLUiEN39Iek2p+5Ji
 AdGK9QP35Wpv1VU+jwUbvxZjZsEwsIBoDkg05Db7569Nis+fq75nGTqLeAwNoDo4BNWl
 GvPnamFtBAA16NJTCS8bRkVQ4p7qOrEozoZhs5RAY9noS/9kocjbyPJbr+xmv/zgtA9U
 cDtQ==
X-Gm-Message-State: AOAM532oYAWghtLOFJqXH76HcMb5ZJKtS25tlUG6y4iZX9ZjLDR1o54h
 Z/+KEH5Jz5cS2mw+fLJ0IklcfoFX2WHwLO3LjfM=
X-Google-Smtp-Source: ABdhPJxHIkkRYMr6U6Ln06QDC0gbJsfnDFK48zjvqBQSAyh4QB19HdTP/stOpfbElK6x14L086b275qsZUdK7+5PfNY=
X-Received: by 2002:a63:9d81:: with SMTP id
 i123mr17900667pgd.176.1591569125731; 
 Sun, 07 Jun 2020 15:32:05 -0700 (PDT)
MIME-Version: 1.0
References: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
 <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark>
 <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com>
In-Reply-To: <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 7 Jun 2020 18:31:54 -0400
Message-ID: <CALZpt+FF0e1wSY5mBY-rVLQu4EGAjQefK9EQDCiExqMvKVc5UQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005fefe905a786109c"
X-Mailman-Approved-At: Mon, 08 Jun 2020 02:02:00 +0000
Cc: Gleb Naumenko <naumenko.gs@gmail.com>
Subject: Re: [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: Sun, 07 Jun 2020 22:32:07 -0000

--0000000000005fefe905a786109c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

> (Of note as well, is that the onchain contract provided by such services
is the same in spirit as those instantiated in channels of the Lightning
Network, thus the same attack schema works on the onchain side.)

If you onchain contract uses a timelock and has concurrent transactions
arbiter by this one , it's subject to time-dilation attack. So yes
submarine swaps, or any kind of atomic swap is concerned. We note this in
discussion.
But you're right for the attack cost, you don't need a channel to these
services, which is also concerning for their attack surface.

> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
strikes me that a mitigation would be to run your Bitcoin fullnode on
clearnet while running your Lightning node over Tor

We clearly mention that risk of running a Bitcoin node over Tor, where do
we recommend running a LN node over Tor ?

>   And this seems to tie with what you propose: that the LN node should
use a different view-fullnode from the broadcast-fullnode.

Yes in Countermeasures - Link layer diversity, specially if it's easy for
an attacker to provoke a transaction broadcast by buying a channel to the
LN node.

> A mitigation to this would be to run a background process which sleeps
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.

Yeah instead of having every node operator running their own hacky scripts,
without them being bulletproofs on detection, I'm working on getting such
mitigations directly in Core, easily deployable for everyone.

> The victim *could* instead check that the absolute timelocks seem very
far in the future relative to its own view of the current blockheight.

I think you're right it's really dependent on CLTV_delta deployed on the
path and time-dilation offset. The alternative you're proposing is a good
one, but you shouldn't know where you're in the path and max CLTV is 2048
blocks IIRC.

Thanks for your reading and review,

Cheers,
Antoine

Le mer. 3 juin 2020 =C3=A0 22:58, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Good morning Gleb and Antoine,
>
> This is good research, thank you for your work.
>
> > **Targeting Per-Hop Packet Delay** is based on routing via the victim,
> and the victim should have at least two channels with the attacker.
>
> The existence of offchain-to-onchain swap services means that the attacke=
r
> needs only build one channel to the victim for this attack to work.
> Rather than route to themselves, the attacker routes to a convenient
> service providing such a swap service, and receives the stolen funds
> onchain, with no need even for an incoming channel from a different node.
> (Of note as well, is that the onchain contract provided by such services
> is the same in spirit as those instantiated in channels of the Lightning
> Network, thus the same attack schema works on the onchain side.)
>
> Indeed, the attack can be mounted on such a service directly.
>
> Even without such a service, the incoming channel need not be directly
> connected to the victim.
>
>
> > [Tor is tricky](https://arxiv.org/abs/1410.6079) too
>
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
> strikes me that a mitigation would be to run your Bitcoin fullnode on
> clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
> "only" loses you the ability to pay, receive, or route (and thereby earn
> forwarding fees), but as long as your blockchain view is clear, it should
> be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin
> node when transactions are broadcast with the attached Bitcoin node (as
> noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some
> random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use =
a
> different view-fullnode from the broadcast-fullnode.
>
>
> > if a node doesn=E2=80=99t observe a block within the last 30 minutes, i=
t
> attempts to make a new random connection to someone in the network.
>
> A mitigation to this would be to run a background process which sleeps fo=
r
> 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
> It might want to `disconnectnode` any previous node it attempted to
> connect to.
>
> However I note that the help for `addnode` contains the text "though such
> peers will not be synced from", which confuses me, since it also refers t=
o
> the `-connect` command line option, and `-connect` means you only connect
> out to the specific nodes, so if those are not synced from.... huh?
>
> And of course the interesting part is "how do we get a `${BITCOINNODE}`
> that we think is not part of the eclipsing attacker?"
>
>
> > If a Lightning node is behind in its Bitcoin blockchain view, but
> Lightning payments between honest nodes are still flowing through it, thi=
s
> node will have a high routing failure rate. This would happen because
> honest nodes on the routing path would reject the forwarded HTLC for bein=
g
> too close to expired.
>
> I am uncertain this would happen very often.
> In the first place, the incoming HTLC would have "reasonable" timeouts, o=
r
> else the incoming honest node would not have routed it at all, and the
> outgoing HTLC would be relative to this incoming one, so the outgoing
> honest node will still accept this.
>
> The victim *could* instead check that the absolute timelocks seem very fa=
r
> in the future relative to its own view of the current blockheight.
> (a forwarding node miht want to do that anyway to have an upper bound
> against griefing attacks)
>
> What would definitely increase in failure rate would be payments arising
> from the victim node; the victim node believes the blockheight to be much
> lower than it actually is, and either the payee node, or some intermediat=
e
> node along the route, will claim to have too little time to safely forwar=
d
> the funds.
> This does not help for nodes which are primarily forwarding nodes.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000005fefe905a786109c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Hi ZmnSCPxj,<br><br>&gt; (Of note as w=
ell, is that the onchain contract provided by such services
 is the same in spirit as those instantiated in channels of the=20
Lightning Network, thus the same attack schema works on the onchain=20
side.)<br><br></div>If you onchain contract uses a timelock and has concurr=
ent transactions arbiter by this one , it&#39;s subject to time-dilation at=
tack. So yes submarine swaps, or any kind of atomic swap is concerned. We n=
ote this in discussion.<br></div>But you&#39;re right for the attack cost, =
you don&#39;t need a channel to these services, which is also concerning fo=
r their attack surface.<br><br>&gt; Since the issue here is that eclipsing =
of Bitcoin nodes is risky, it=20
strikes me that a mitigation would be to run your Bitcoin fullnode on=20
clearnet while running your Lightning node over Tor
<br><br></div>We clearly mention that risk of running a Bitcoin node over T=
or, where do we recommend running a LN node over Tor ?<br><br>&gt; =C2=A0 A=
nd this seems to tie with what you propose: that the LN node should use a d=
ifferent view-fullnode from the broadcast-fullnode.<br><br></div>Yes in Cou=
ntermeasures - Link layer diversity, specially if it&#39;s easy for an atta=
cker to provoke a transaction broadcast by buying a channel to the LN node.=
<br><br>&gt; A mitigation to this would be to run a background process whic=
h sleeps=20
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.<div>=
<br></div><div>Yeah instead of having every node operator running their own=
 hacky scripts, without them being bulletproofs on detection, I&#39;m worki=
ng on getting such mitigations directly in Core, easily deployable for ever=
yone.<br><br>&gt; The victim *could* instead check that the absolute timelo=
cks seem very=20
far in the future relative to its own view of the current blockheight.<br><=
br></div><div>I think you&#39;re right it&#39;s really dependent on CLTV_de=
lta deployed on the path and time-dilation offset. The alternative you&#39;=
re proposing is a good one, but you shouldn&#39;t know where you&#39;re in =
the path and max CLTV is 2048 blocks IIRC.<br><br></div><div>Thanks for you=
r reading and review,<br><br></div><div>Cheers,<br></div><div>Antoine<br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">Le=C2=A0mer. 3 juin 2020 =C3=A0=C2=A022:58, ZmnSCPxj via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Good morning Gleb and Antoine,<br>
<br>
This is good research, thank you for your work.<br>
<br>
&gt; **Targeting Per-Hop Packet Delay** is based on routing via the victim,=
 and the victim should have at least two channels with the attacker.<br>
<br>
The existence of offchain-to-onchain swap services means that the attacker =
needs only build one channel to the victim for this attack to work.<br>
Rather than route to themselves, the attacker routes to a convenient servic=
e providing such a swap service, and receives the stolen funds onchain, wit=
h no need even for an incoming channel from a different node.<br>
(Of note as well, is that the onchain contract provided by such services is=
 the same in spirit as those instantiated in channels of the Lightning Netw=
ork, thus the same attack schema works on the onchain side.)<br>
<br>
Indeed, the attack can be mounted on such a service directly.<br>
<br>
Even without such a service, the incoming channel need not be directly conn=
ected to the victim.<br>
<br>
<br>
&gt; [Tor is tricky](<a href=3D"https://arxiv.org/abs/1410.6079" rel=3D"nor=
eferrer" target=3D"_blank">https://arxiv.org/abs/1410.6079</a>) too<br>
<br>
Since the issue here is that eclipsing of Bitcoin nodes is risky, it strike=
s me that a mitigation would be to run your Bitcoin fullnode on clearnet wh=
ile running your Lightning node over Tor.<br>
Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) &=
quot;only&quot; loses you the ability to pay, receive, or route (and thereb=
y earn forwarding fees), but as long as your blockchain view is clear, it s=
hould be fine.<br>
<br>
Of course, the Lightning node could still be correlated with the Bitcoin no=
de when transactions are broadcast with the attached Bitcoin node (as noted=
 in the paper).<br>
Instead the Lightning node should probably connect, over Tor, to some rando=
m Bitcoin fullnodes / Electrum servers and broadcast txes to them.<br>
<br>
And this seems to tie with what you propose: that the LN node should use a =
different view-fullnode from the broadcast-fullnode.<br>
<br>
<br>
&gt; if a node doesn=E2=80=99t observe a block within the last 30 minutes, =
it attempts to make a new random connection to someone in the network.<br>
<br>
A mitigation to this would be to run a background process which sleeps for =
20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.<br>
It might want to `disconnectnode` any previous node it attempted to connect=
 to.<br>
<br>
However I note that the help for `addnode` contains the text &quot;though s=
uch peers will not be synced from&quot;, which confuses me, since it also r=
efers to the `-connect` command line option, and `-connect` means you only =
connect out to the specific nodes, so if those are not synced from.... huh?=
<br>
<br>
And of course the interesting part is &quot;how do we get a `${BITCOINNODE}=
` that we think is not part of the eclipsing attacker?&quot;<br>
<br>
<br>
&gt; If a Lightning node is behind in its Bitcoin blockchain view, but Ligh=
tning payments between honest nodes are still flowing through it, this node=
 will have a high routing failure rate. This would happen because honest no=
des on the routing path would reject the forwarded HTLC for being too close=
 to expired.<br>
<br>
I am uncertain this would happen very often.<br>
In the first place, the incoming HTLC would have &quot;reasonable&quot; tim=
eouts, or else the incoming honest node would not have routed it at all, an=
d the outgoing HTLC would be relative to this incoming one, so the outgoing=
 honest node will still accept this.<br>
<br>
The victim *could* instead check that the absolute timelocks seem very far =
in the future relative to its own view of the current blockheight.<br>
(a forwarding node miht want to do that anyway to have an upper bound again=
st griefing attacks)<br>
<br>
What would definitely increase in failure rate would be payments arising fr=
om the victim node; the victim node believes the blockheight to be much low=
er than it actually is, and either the payee node, or some intermediate nod=
e along the route, will claim to have too little time to safely forward the=
 funds.<br>
This does not help for nodes which are primarily forwarding nodes.<br>
<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005fefe905a786109c--