public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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
Date: Thu, 11 Jun 2020 05:21:48 -0400	[thread overview]
Message-ID: <CALZpt+FPr2ymQ7x_w8pj0RX2eLoSRykUJH22HM1Z0pZy4cj-mQ@mail.gmail.com> (raw)
In-Reply-To: <SVoahCvNBv1S9IXAtG65zld__i5Q_Il9RAzkRLe2LX4JKt4fAxVFyttNp22IYsODv8uAzmWeQNjXORXwuiF9Xm4WeVDrWsaSh2o-KnCEFfw=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]

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/bitcoin/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 à 19:35, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

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

[-- Attachment #2: Type: text/html, Size: 5000 bytes --]

      reply	other threads:[~2020-06-11  9:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
2020-06-03 16:20 ` [bitcoin-dev] Time-dilation Attacks on the Lightning Network Gleb Naumenko
2020-06-04  2:58   ` ZmnSCPxj
2020-06-05 10:10     ` Aymeric Vitte
2020-06-05 11:44       ` ZmnSCPxj
2020-06-05 15:41         ` Aymeric Vitte
2020-06-07 22:31     ` Antoine Riard
2020-06-08  4:56       ` ZmnSCPxj
2020-06-08 16:43         ` Aymeric Vitte
2020-06-10 23:34       ` ZmnSCPxj
2020-06-11  9:21         ` Antoine Riard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALZpt+FPr2ymQ7x_w8pj0RX2eLoSRykUJH22HM1Z0pZy4cj-mQ@mail.gmail.com \
    --to=antoine.riard@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=naumenko.gs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox