From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA275C016F for ; Mon, 8 Jun 2020 04:57:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id B0B0D87A15 for ; Mon, 8 Jun 2020 04:57:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4Q7MZBiErMR for ; Mon, 8 Jun 2020 04:57:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by hemlock.osuosl.org (Postfix) with ESMTPS id D0B09879F0 for ; Mon, 8 Jun 2020 04:57:07 +0000 (UTC) Date: Mon, 08 Jun 2020 04:56:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591592224; bh=8BH5FJiv6/RGbwwd7jCgLBxv/N3DkePXY2NByQ1TCwU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=JXRbNRPP9Tw0I2/0xF4V55TxPUbKNa8IXgv8y5WS7FJbj/NgjwXYyFrq0JxnF3pIz zf3Wq3KH/D2/KdQq9GLbvjiiWwro4fq5wdWKas1TuEixXKkGFed7r22f2eQXP2LVIp fYBMBjS6ZHdSZhG9jdDJsrgR+VdxcmuW/nzaBbR4= To: Antoine Riard From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <0c12JSDyiAy6W118uPNSz2mGj53mOB1a88HBgN5icKHMyUCIW3iCjuscuwQxpniW6sxEwLi51UujOXSwBhsWD3KmQlFBADJ5vRU0Xr1YUz0=@protonmail.com> In-Reply-To: References: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark> <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark> <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Gleb Naumenko , Bitcoin Protocol Discussion 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: Mon, 08 Jun 2020 04:57:09 -0000 Good morning Antoine, > > Since the issue here is that eclipsing of Bitcoin nodes is risky, it st= rikes me that a mitigation would be to run your Bitcoin fullnode on clearne= t 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 ? Nowhere, *I* am the one recommending this. Running both Bitcoin and Lightning nodes on clearnet automatically links th= em, making them easier to attack, whereas running Lightning on Tor does not= . Of course, they could still be linked by onchain transaction monitoring, bu= t at least this increases the effort to attack, hopefully it becomes margin= ally less desirable to attack you. On the other hand, you *could* run them on different public IP addresses, i= f you happen to have more than one; for those who do not even have a single= public IP address there is no real choice if you want to let others to con= nect to you, Tor hidden service is the only Lightning-supported way to be a= ccessible without a public IP. (There are sections of the world where commodity "home" internet connection= s do not automatically get a public IP, and the privilege of getting one ma= y be an additional cost; though of course if you have no real intent to hel= p support either the Bitcoin or Lightning networks, you do not need a publi= c IP anyway, and with IPv6 it becomes less and less likely that a randomly-= chosen entity would be unlucky enough to not get a public IP.) > > 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 o= ne, but you shouldn't know where you're in the path and max CLTV is 2048 bl= ocks IIRC. Seeing an incoming payment that violates the max CLTV is a good indication = you have been eclipsed. On the other hand, if your Bitcoin node is eclipsed, then it seems likely y= our Lightning node is also eclipsed (if running over the same hardware) and= you might not receive any indication over Lightning that you have been ecl= ipsed anyway. I suppose we need to identify just exactly *what* ways a node of either typ= e can be eclipsed; it seems that mitigations that protect against one kind = of eclipse will not work in general with other kinds of eclipse. Regards, ZmnSCPxj