1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0E938C016E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jun 2020 02:58:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id F197821F76
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jun 2020 02:58:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Znchxw9pQOjA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jun 2020 02:58:31 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by silver.osuosl.org (Postfix) with ESMTPS id B44C020454
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jun 2020 02:58:31 +0000 (UTC)
Date: Thu, 04 Jun 2020 02:58:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1591239509;
bh=DMPJLMskd/q7frivrSgvm/QowCMUOpYoYoJMSbA5Dng=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=X/L3GFTDSqnWBw5gHDevEPwoo+gKirrW6wlOabCiipQHnEQOQSQGTodTXw/b/IRu6
N5tzroNiRScY6xTGF7KHM9KAK28C4WHltRBQhoPUlOT1kHeFeyGoVRlNFKRWYHrNHi
I7eyN7tSQXiL46J72uu/n4VPyQwRpDfzJurmc6Lk=
To: Gleb Naumenko <naumenko.gs@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com>
In-Reply-To: <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark>
References: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
<9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 04 Jun 2020 02:58:34 -0000
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, an=
d the victim should have at least two channels with the attacker.
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.
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.
(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.)
Indeed, the attack can be mounted on such a service directly.
Even without such a service, the incoming channel need not be directly conn=
ected 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 strike=
s me that a mitigation would be to run your Bitcoin fullnode on clearnet wh=
ile 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 for=
warding fees), but as long as your blockchain view is clear, it should be f=
ine.
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).
Instead the Lightning node should probably connect, over Tor, to some rando=
m 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, it =
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 for =
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 p=
eers will not be synced from", which confuses me, since it also refers to t=
he `-connect` command line option, and `-connect` means you only connect ou=
t 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}` tha=
t we think is not part of the eclipsing attacker?"
> If a Lightning node is behind in its Bitcoin blockchain view, but Lightni=
ng payments between honest nodes are still flowing through it, this node wi=
ll have a high routing failure rate. This would happen because honest nodes=
on the routing path would reject the forwarded HTLC for being too close to=
expired.
I am uncertain this would happen very often.
In the first place, the incoming HTLC would have "reasonable" timeouts, or =
else the incoming honest node would not have routed it at all, and the outg=
oing HTLC would be relative to this incoming one, so the outgoing honest no=
de will still accept this.
The victim *could* instead check that the absolute timelocks seem very far =
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 again=
st griefing attacks)
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.
This does not help for nodes which are primarily forwarding nodes.
Regards,
ZmnSCPxj
|
