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 F34CAC016F for ; Thu, 11 Jun 2020 09:22:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id DDACE25175 for ; Thu, 11 Jun 2020 09:22:02 +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 Uyh+x2I6+jSm for ; Thu, 11 Jun 2020 09:22:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by silver.osuosl.org (Postfix) with ESMTPS id 34EB72042D for ; Thu, 11 Jun 2020 09:22:01 +0000 (UTC) Received: by mail-pl1-f195.google.com with SMTP id bh7so2103452plb.11 for ; Thu, 11 Jun 2020 02:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y7sg0At4TBwRZyn48eeTSOgIGqVXl9qe2tJInpCvdxA=; b=mSSooWkvKBD+ATSxWCAn/luRg+3PRiwfPWN2QmuTbKgIg8Yiya6zG/OHdHkM4VW4Ut qsXtgD4cUMPvuYroHuxxvF7M8G0+BW2ebHnFvIBpPRuYJ6UXrxrCrG/L57Hu9K7NzXk0 74yo7JB5sWacYy/ewpnkh6bsCnZ9lUsWR4rifx0lhNv+6J5LLqYG/7IqQyZwCXipzkvL IbJ0ydEzB4PoHBJiDUR21fwQ6h5QnK+AfnKl8PXqHCRP4GxwidLsAZMEU9hjjnf/UWHD eSt+wRnK/UQFmTGHyYNRj+1tNhbE52eNsJu/MR7ut1Ry+9fpcnQX4TptPyjaPahRuj3x cuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y7sg0At4TBwRZyn48eeTSOgIGqVXl9qe2tJInpCvdxA=; b=RnVBewZZIusU785JcMCm0AerCN03gAPmJkQB7EhCp1588FALdjGGzGZVoKkJDt9KQW RrribwpR5kDhwGqDtfAtaWlZHJgdnqLoZY0rRUdXWkHJMFUzC4P25uCTDU016FQfJ2IS GgaxGe3JsD4pYABun3TigvTUI+ryjZiHKR9cO5VeChUuB0OP0Meis247DAhmOX1tVMFc LyA37EcjASRgdLGTHdNxxnHSm7F4h2m5rEXz8qLAuLRec7ozMZ1NgNJ/2X5V7gOdRzWP XZ37nzUGUVi/T6UZjsMGZ/LHoWNZ+40N44xke01OipfAjaCFipGAxGJ+neR2/KRBBXFU N3Jw== X-Gm-Message-State: AOAM530q1MIGIJynFpu+wYT/57Dkn6stLaA6NAPs5Df9QxLot+JoGkDy nVNyGhy4MnRgx2CyYfJi7l0soMdpZ8HmsOffYRw= X-Google-Smtp-Source: ABdhPJwlGc+Bs8BX54iJC6+smZ5S1383E26c0m23TYPidaCoHURokYcHa1EOYy+mfFmQwL7rIR6505FFMCL89XXCVDM= X-Received: by 2002:a17:90a:d3d7:: with SMTP id d23mr6998424pjw.233.1591867320695; Thu, 11 Jun 2020 02:22:00 -0700 (PDT) MIME-Version: 1.0 References: <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark> <9e4dfaa7-895a-48a1-8116-eaafc80da34f@Spark> <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com> In-Reply-To: From: Antoine Riard Date: Thu, 11 Jun 2020 05:21:48 -0400 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000002dfd2105a7cb7e18" X-Mailman-Approved-At: Thu, 11 Jun 2020 09:23:26 +0000 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: Thu, 11 Jun 2020 09:22:03 -0000 --0000000000002dfd2105a7cb7e18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj Well your deeclipser is already WIP ;) See my AltNet+Watchdog proposals in Core: https://github.com/bitcoin/bitcoin/pull/18987/https://github.com/bitcoin/bi= tcoin/pull/18988 It's almost covering what you mention, a driver framework to plug alternative transports protocols : radio, DNS, even LN Noise, Tor's Snowflake... Proposal is a PoC with a multi-threaded process but yes I want production-design to be a multi-process for the reasons you mentioned. Drivers should be developed out-of-tree but with an interface to plug them smoothly (tm). Proposal is more generic than pure LN, like some privacy-concerned users may want to broadcast by default their transactions over radio. But for LN support it should a) detect network/block issuance anomalies b) dynamically react by closing channels or c) fetch headers/blocks through redundant communication channels and d) provide emergency transactions broadcast if your time-sensitive transactions are censored. It's long-term work so be patient but getting opt-in support in Core would make it far easier for any LN routing/vaulting node to deploy it. In the meanwhile you can have multiple nodes on different infrastructures to serve as a backend for your LN node. Bonus: if LN nodes are incentivized to deploy such strong anti-eclipsing measures to mitigate time-dilation it would benefit base layer p2p security network-wise. In case of network partition, your node with link layer redundancy will keep it in-sync its connected peers on the same side of the partition, even if they don't deploy anything. I'm sure you have improvements to suggest ! Best, Antoine Le mer. 10 juin 2020 =C3=A0 19:35, ZmnSCPxj a =C3= =A9crit : > Good morning Antoine and Gleb, > > One thing I have been idly thinking about would be to have a *separate* > software daemon that performs de-eclipsing for your Bitcoin fullnode. > > For example, you could run this deeclipser on the same hardware as your > Bitcoin fullnode, and have the deeclipser bind to port 8334. > Then you set your Bitcoin fullnode with `addnode=3Dlocalhost:8334` in you= r > `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 > latest headers known by your fullnode, via the P2P protocol connection yo= ur > fullnode 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 > deeclipser 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 > their 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 your fullnode to update it. > > The advantage of using a plugin system is that it becomes easier to > prototype, deploy, and maybe even test new de-eclipsing mitigations. > > At the same time, by running a separate daemon from the fullnode, we > provide some amount of process isolation in case some problem with the > plugin system exists. > The deeclipser could be run by a completely different user, for example, > and you might even run multiple deeclipser daemons in the same hardware, > with different non-overlapping plugins, so that an exploit of one plugin > will only bring down one deeclipser, with other deeclipser daemons > remaining functional and still protecting your fullnode. > > Finally, by using the P2P protocol, the fullnode you run could be a > non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin or whatever other > fullnode implementations exist, assuming you actually want to use them fo= r > some reason. > > What do you think? > > Regards, > ZmnSCPxj > > --0000000000002dfd2105a7cb7e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj

Wel= l your deeclipser is already WIP ;)

See my AltNet+W= atchdog proposals in Core: https://github.com/= bitcoin/bitcoin/pull/18987/https://github.com/bitcoin/bitcoin/pull/18988

It's almost covering what you mention, a driver fra= mework to plug alternative transports protocols : radio, DNS, even LN Noise= , Tor's Snowflake... Proposal is a PoC with a multi-threaded process bu= t yes I want production-design to be a multi-process for the reasons you me= ntioned. Drivers should be developed out-of-tree but with an interface to p= lug them smoothly (tm).

Proposal is more generic than pure LN, like = some privacy-concerned users may want to broadcast by default their transac= tions over radio. But for LN support it should a) detect network/block issu= ance anomalies b) dynamically react by closing channels or c) fetch headers= /blocks through redundant communication channels and d) provide emergency t= ransactions broadcast if your time-sensitive transactions are censored.
=

It's long-term work so be patient but getting opt-in su= pport in Core would make it far easier for any LN routing/vaulting node to = deploy it. In the meanwhile you can have multiple nodes on different infras= tructures to serve as a backend for your LN node.

Bonus: if LN= nodes are incentivized to deploy such strong anti-eclipsing measures to mi= tigate time-dilation it would benefit base layer p2p security network-wise.= In case of network partition, your node with link layer redundancy will ke= ep it in-sync its connected peers on the same side of the partition, even i= f they don't deploy anything.

I'm sure you have improv= ements to suggest !

Best,
Antoine

=

= Le=C2=A0mer. 10 juin 2020 =C3=A0=C2=A019:35, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=A9crit=C2= =A0:
Good mornin= g 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

--0000000000002dfd2105a7cb7e18--