path: root/fb/3efda27244df92fef4a421cebbaadf4efd3e6b

Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F34CAC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 09:22:01 +0000 (UTC)
Received: by mail-pl1-f195.google.com with SMTP id bh7so2103452plb.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <CALZpt+FF0e1wSY5mBY-rVLQu4EGAjQefK9EQDCiExqMvKVc5UQ@mail.gmail.com>
 <SVoahCvNBv1S9IXAtG65zld__i5Q_Il9RAzkRLe2LX4JKt4fAxVFyttNp22IYsODv8uAzmWeQNjXORXwuiF9Xm4WeVDrWsaSh2o-KnCEFfw=@protonmail.com>
In-Reply-To: <SVoahCvNBv1S9IXAtG65zld__i5Q_Il9RAzkRLe2LX4JKt4fAxVFyttNp22IYsODv8uAzmWeQNjXORXwuiF9Xm4WeVDrWsaSh2o-KnCEFfw=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 11 Jun 2020 05:21:48 -0400
Message-ID: <CALZpt+FPr2ymQ7x_w8pj0RX2eLoSRykUJH22HM1Z0pZy4cj-mQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000002dfd2105a7cb7e18"
X-Mailman-Approved-At: Thu, 11 Jun 2020 09:23:26 +0000
Cc: Gleb Naumenko <naumenko.gs@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <ZmnSCPxj@protonmail.com> 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

<div dir=3D"ltr"><div><div><div><div><div>Hi ZmnSCPxj<br><br></div><div>Wel=
l your deeclipser is already WIP ;)<br></div><div><br></div>See my AltNet+W=
atchdog proposals in Core: <a href=3D"https://github.com/bitcoin/bitcoin/pu=
ll/18987/https://github.com/bitcoin/bitcoin/pull/18988">https://github.com/=
bitcoin/bitcoin/pull/18987/https://github.com/bitcoin/bitcoin/pull/18988</a=
><br><br></div><div>It&#39;s almost covering what you mention, a driver fra=
mework to plug alternative transports protocols : radio, DNS, even LN Noise=
, Tor&#39;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).<br><br>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.<br>=
</div><br></div>It&#39;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.<br><br></div>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&#39;t deploy anything.<br><br></div>I&#39;m sure you have improv=
ements to suggest !<br><div><div><div><div><div><div><br></div><div>Best,<b=
r></div><div>Antoine<br></div><div><br></div></div></div></div></div></div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
Le=C2=A0mer. 10 juin 2020 =C3=A0=C2=A019:35, ZmnSCPxj &lt;<a href=3D"mailto=
:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good mornin=
g Antoine and Gleb,<br>
<br>
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.<br>
<br>
For example, you could run this deeclipser on the same hardware as your Bit=
coin fullnode, and have the deeclipser bind to port 8334.<br>
Then you set your Bitcoin fullnode with `addnode=3Dlocalhost:8334` in your =
`bitcoind.conf`.<br>
<br>
Your Bitcoin fullnode would then connect to the deeclipser using normal P2P=
 protocol.<br>
<br>
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.<br>
Then it would attempt to discover any blocks with greater blockheight.<br>
<br>
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.<br>
For example, the deeclipser could query a number of plugins:<br>
<br>
* One plugin could just try connecting to some random node, in the hopes of=
 getting a new connection that is not eclipsed.<br>
* Another plugin could try polling known blockchain explorers and using the=
ir APIs over HTTPS, possibly over Tor as well.<br>
* Another plugin could try connecting to known Electrum servers.<br>
* New plugins can be developed for new mitigations, such as sending headers=
 over DNS or blocks over mesh or etc.<br>
<br>
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.<br>
<br>
The advantage of using a plugin system is that it becomes easier to prototy=
pe, deploy, and maybe even test new de-eclipsing mitigations.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
What do you think?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>

--0000000000002dfd2105a7cb7e18--