Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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=localhost: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 latest headers known by your fullnode, via the P2P protocol connection your 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 for some reason.

What do you think?

Regards,
ZmnSCPxj