Date: Thu, 04 Jun 2020 02:58:24 +0000
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
Precedence: list

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