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"
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
Precedence: list

--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--