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 2AFD9C016F for ; Wed, 10 Jun 2020 23:35:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 0F2BD24E91 for ; Wed, 10 Jun 2020 23:35:04 +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 ZELQWIMpfZam for ; Wed, 10 Jun 2020 23:35:01 +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 silver.osuosl.org (Postfix) with ESMTPS id 8B0EE2441E for ; Wed, 10 Jun 2020 23:35:01 +0000 (UTC) Date: Wed, 10 Jun 2020 23:34:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591832099; bh=KChQzBnnUtA1jVycDOyC0IGWT7Cw6W4Mm0omn3aTY+I=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=a8OXZ8cxipmB3FUF8aehAw3ZJN70GJ8qcE5KfZpoczy3084cc0pzLZ2hpIwky4huZ KTBmLQ15eyBDx+wtx4Czi4I3K0SqycA0UJHT1PfLeZuQ/Kxv00jnhQ5m6aCQbRnUSZ tP587dL1mFdek9vzRi9HwVZg5x9DksKP0dZHJfEI= To: Antoine Riard From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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: Wed, 10 Jun 2020 23:35:04 -0000 Good morning Antoine and Gleb, One thing I have been idly thinking about would be to have a *separate* sof= tware daemon that performs de-eclipsing for your Bitcoin fullnode. For example, you could run this deeclipser on the same hardware as your Bit= coin fullnode, and have the deeclipser bind to port 8334. Then you set your Bitcoin fullnode with `addnode=3Dlocalhost:8334` in your = `bitcoind.conf`. Your Bitcoin fullnode would then connect to the deeclipser using normal P2P= protocol. The deeclipser would periodically, every five minutes or so, check the late= st headers known by your fullnode, via the P2P protocol connection your ful= lnode makes. Then it would attempt to discover any blocks with greater blockheight. The reason why we have a separate deeclipser process is so that the deeclip= ser can use a plugin system, and isolate the plugins from the main fullnode= software. For example, the deeclipser could query a number of plugins: * One plugin could just try connecting to some random node, in the hopes of= getting a new connection that is not eclipsed. * Another plugin could try polling known blockchain explorers and using the= ir APIs over HTTPS, possibly over Tor as well. * Another plugin could try connecting to known Electrum servers. * New plugins can be developed for new mitigations, such as sending headers= over DNS or blocks over mesh or etc. Then if any plugin discovers a block later than that known by your fullnode= , the deeclipser can send an unsolicited `block` or `header` message to you= r fullnode to update it. The advantage of using a plugin system is that it becomes easier to prototy= pe, deploy, and maybe even test new de-eclipsing mitigations. At the same time, by running a separate daemon from the fullnode, we provid= e some amount of process isolation in case some problem with the plugin sys= tem exists. The deeclipser could be run by a completely different user, for example, an= d you might even run multiple deeclipser daemons in the same hardware, with= different non-overlapping plugins, so that an exploit of one plugin will o= nly bring down one deeclipser, with other deeclipser daemons remaining func= tional and still protecting your fullnode. Finally, by using the P2P protocol, the fullnode you run could be a non-Bit= coin-Core fullnode, such as btcd or rust-bitcoin or whatever other fullnode= implementations exist, assuming you actually want to use them for some rea= son. What do you think? Regards, ZmnSCPxj