From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0E938C016E for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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