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

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

[Gleb Naumenko]

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

Hi! I and Antoine Riard explored time-dilation attacks on Lightning.

We have a blogpost, which is probably too long to include in the email in full.
You can read it here: https://discrete-blog.github.io/time-dilation/
There’s also a paper we wrote: https://arxiv.org/abs/2006.01418


We believe this work should be interesting for anyone curious/excited about LN or other second-layer protocols in Bitcoin. We are very interested in your opinions!

Now, let me share the intro from the post with you (which is really a summary of the work), since it’s about the right size for a mailing list post. Hopefully, it would motivate you to read further.

Protocols on top of the Bitcoin base layer are really cool. They offer tremendous opportunities in terms of scalability, confidentiality, and functionality, at a cost of new security assumptions.

We all know payment channels have to be monitored, otherwise, the funds can be stolen. That sounds too abstract though. We decided to study what an attacker actually has to do to steal funds from LN users.

More specifically, we explored how peer-to-peer layer attacks can help with breaking the assumption above. Per time-dilation attacks, an attacker controls the victim’s access to the Bitcoin network (hard, but not impossible) and delays block delivery to the victim. After that, the attacker exploits that the victim can’t access recent blocks in a timely manner. In some cases, it is enough to isolate the victim only for two hours.

Then the attacker makes a couple (totally legit) actions on the Lightning Network towards the victim’s channels, and at the same time commits a different state instead. Since the victim is behind in terms of the latest blockchain tip, they cannot detect this and react as required by the protocol.

We demonstrate three different ways the attacker can steal funds from the victim, and discuss the feasibility/cost of these attacks. We also explore the broad scope of countermeasures, which may significantly increase the attack cost.

In short, the takeaways from our work are:

1. Many Lightning users (those with Bitcoin light clients) are currently vulnerable to Eclipse attacks.
2. Those Lightning users which run Bitcoin Core full nodes are more robust to Eclipse attacks, but the attacks are still possible as recent research suggests.
3. Eclipse attacks enable stealing funds via time-dilation.
4. Time-dilation attacks can’t be mitigated with just observing slow block arrival, so there is no simple solution to (3).
5. Thus, time-dilation is a practical way to steal funds from eclipsed users. Neither it requires hashrate nor targets merchants only. Light client users are a good target because they are easy to attack. Full node users are a good target because they are often used by major hubs (or service providers), and stealing their aggregate liquidiy might justify the high attack cost.
6. Strong anti-Eclipse measures is the key solution. WatchTowers are cool too.


Best,

Gleb Naumenko and Antoine Riard

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

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

[ZmnSCPxj]

Good morning Gleb and Antoine,

This is good research, thank you for your work.

> **Targeting Per-Hop Packet Delay** is based on routing via the victim, and the victim should have at least two channels with the attacker.

The existence of offchain-to-onchain swap services means that the attacker needs only build one channel to the victim for this attack to work.
Rather than route to themselves, the attacker routes to a convenient service providing such a swap service, and receives the stolen funds onchain, with no need even for an incoming channel from a different node.
(Of note as well, is that the onchain contract provided by such services is the same in spirit as those instantiated in channels of the Lightning Network, thus the same attack schema works on the onchain side.)

Indeed, the attack can be mounted on such a service directly.

Even without such a service, the incoming channel need not be directly connected to the victim.


> [Tor is tricky](https://arxiv.org/abs/1410.6079) too

Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me that a mitigation would be to run your Bitcoin fullnode on clearnet while running your Lightning node over Tor.
Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.

Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.

And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.


> if a node doesn’t observe a block within the last 30 minutes, it attempts to make a new random connection to someone in the network.

A mitigation to this would be to run a background process which sleeps for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
It might want to `disconnectnode` any previous node it attempted to connect to.

However I note that the help for `addnode` contains the text "though such peers will not be synced from", which confuses me, since it also refers to the `-connect` command line option, and `-connect` means you only connect out to the specific nodes, so if those are not synced from.... huh?

And of course the interesting part is "how do we get a `${BITCOINNODE}` that we think is not part of the eclipsing attacker?"


> If a Lightning node is behind in its Bitcoin blockchain view, but Lightning payments between honest nodes are still flowing through it, this node will have a high routing failure rate. This would happen because honest nodes on the routing path would reject the forwarded HTLC for being too close to expired.

I am uncertain this would happen very often.
In the first place, the incoming HTLC would have "reasonable" timeouts, or else the incoming honest node would not have routed it at all, and the outgoing HTLC would be relative to this incoming one, so the outgoing honest node will still accept this.

The victim *could* instead check that the absolute timelocks seem very far in the future relative to its own view of the current blockheight.
(a forwarding node miht want to do that anyway to have an upper bound against griefing attacks)

What would definitely increase in failure rate would be payments arising from the victim node; the victim node believes the blockheight to be much lower than it actually is, and either the payee node, or some intermediate node along the route, will claim to have too little time to safely forward the funds.
This does not help for nodes which are primarily forwarding nodes.



Regards,
ZmnSCPxj

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

[Aymeric Vitte]

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


Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit :
>> [Tor is tricky](https://arxiv.org/abs/1410.6079) too
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me that a mitigation would be to run your Bitcoin fullnode on clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.
>

The issue each time there are discussions/research linking to Tor is
that it is biased since the beginning because based on a wrong
postulate: using the Tor network

I will not elaborate on this again, it's an obvious very bad idea to use
the Tor network for bitcoin

It's not a bad idea to use the Tor protocol with no story of exit nodes
and hidden services, linking again to:
https://github.com/Ayms/node-Tor#phase-4-and-phase-5

And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
and generic architecture to anonymize any application or protocol and
turn it into an independent decentralized p2p network inside browsers
and servers, with browsers acting as servers"

LN and bitcoin nodes would be relays and/or RDV points and/or clients
and serving parties, some Tor network nodes could be used in the middle
also (relays only) but in any case sybils/eclipse attacks become much
more difficult to perform (or unlikely depending on how the peer
discovery system is designed)

bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)

Then question for possible future tests: is there a simple way to pipe
the bitcoin protocol via stdin/stdout? (the socks interface could be
used but we already saw that it did raise issues)

-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


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

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

[ZmnSCPxj]

Good morning Aymeric,

> The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network
>

Well, in the interest of using the wrong tool for a highly important job, let me present this thought:

* The Tor network is weakened due to its dependence on a limited set of exit nodes.
* "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
* Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
* Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
* So make your own bridge between Tor and clearnet.
* Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
* One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
* The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
* Use the Tor-fullnode to propagate your transactions.

Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.

Regards,
ZmnSCPxj

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

[Aymeric Vitte]

Hi,

As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves

Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered

Regards,

Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.

Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings

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

[Antoine Riard]

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

Hi ZmnSCPxj,

> (Of note as well, is that the onchain contract provided by such services
is the same in spirit as those instantiated in channels of the Lightning
Network, thus the same attack schema works on the onchain side.)

If you onchain contract uses a timelock and has concurrent transactions
arbiter by this one , it's subject to time-dilation attack. So yes
submarine swaps, or any kind of atomic swap is concerned. We note this in
discussion.
But you're right for the attack cost, you don't need a channel to these
services, which is also concerning for their attack surface.

> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
strikes me that a mitigation would be to run your Bitcoin fullnode on
clearnet while running your Lightning node over Tor

We clearly mention that risk of running a Bitcoin node over Tor, where do
we recommend running a LN node over Tor ?

>   And this seems to tie with what you propose: that the LN node should
use a different view-fullnode from the broadcast-fullnode.

Yes in Countermeasures - Link layer diversity, specially if it's easy for
an attacker to provoke a transaction broadcast by buying a channel to the
LN node.

> A mitigation to this would be to run a background process which sleeps
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.

Yeah instead of having every node operator running their own hacky scripts,
without them being bulletproofs on detection, I'm working on getting such
mitigations directly in Core, easily deployable for everyone.

> The victim *could* instead check that the absolute timelocks seem very
far in the future relative to its own view of the current blockheight.

I think you're right it's really dependent on CLTV_delta deployed on the
path and time-dilation offset. The alternative you're proposing is a good
one, but you shouldn't know where you're in the path and max CLTV is 2048
blocks IIRC.

Thanks for your reading and review,

Cheers,
Antoine

Le mer. 3 juin 2020 à 22:58, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Good morning Gleb and Antoine,
>
> This is good research, thank you for your work.
>
> > **Targeting Per-Hop Packet Delay** is based on routing via the victim,
> and the victim should have at least two channels with the attacker.
>
> The existence of offchain-to-onchain swap services means that the attacker
> needs only build one channel to the victim for this attack to work.
> Rather than route to themselves, the attacker routes to a convenient
> service providing such a swap service, and receives the stolen funds
> onchain, with no need even for an incoming channel from a different node.
> (Of note as well, is that the onchain contract provided by such services
> is the same in spirit as those instantiated in channels of the Lightning
> Network, thus the same attack schema works on the onchain side.)
>
> Indeed, the attack can be mounted on such a service directly.
>
> Even without such a service, the incoming channel need not be directly
> connected to the victim.
>
>
> > [Tor is tricky](https://arxiv.org/abs/1410.6079) too
>
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
> strikes me that a mitigation would be to run your Bitcoin fullnode on
> clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
> "only" loses you the ability to pay, receive, or route (and thereby earn
> forwarding fees), but as long as your blockchain view is clear, it should
> be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin
> node when transactions are broadcast with the attached Bitcoin node (as
> noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some
> random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a
> different view-fullnode from the broadcast-fullnode.
>
>
> > if a node doesn’t observe a block within the last 30 minutes, it
> attempts to make a new random connection to someone in the network.
>
> A mitigation to this would be to run a background process which sleeps for
> 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
> It might want to `disconnectnode` any previous node it attempted to
> connect to.
>
> However I note that the help for `addnode` contains the text "though such
> peers will not be synced from", which confuses me, since it also refers to
> the `-connect` command line option, and `-connect` means you only connect
> out to the specific nodes, so if those are not synced from.... huh?
>
> And of course the interesting part is "how do we get a `${BITCOINNODE}`
> that we think is not part of the eclipsing attacker?"
>
>
> > If a Lightning node is behind in its Bitcoin blockchain view, but
> Lightning payments between honest nodes are still flowing through it, this
> node will have a high routing failure rate. This would happen because
> honest nodes on the routing path would reject the forwarded HTLC for being
> too close to expired.
>
> I am uncertain this would happen very often.
> In the first place, the incoming HTLC would have "reasonable" timeouts, or
> else the incoming honest node would not have routed it at all, and the
> outgoing HTLC would be relative to this incoming one, so the outgoing
> honest node will still accept this.
>
> The victim *could* instead check that the absolute timelocks seem very far
> in the future relative to its own view of the current blockheight.
> (a forwarding node miht want to do that anyway to have an upper bound
> against griefing attacks)
>
> What would definitely increase in failure rate would be payments arising
> from the victim node; the victim node believes the blockheight to be much
> lower than it actually is, and either the payee node, or some intermediate
> node along the route, will claim to have too little time to safely forward
> the funds.
> This does not help for nodes which are primarily forwarding nodes.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[ZmnSCPxj]

Good morning Antoine,


> > Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me that a mitigation would be to run your Bitcoin fullnode on clearnet while running your Lightning node over Tor
>
> We clearly mention that risk of running a Bitcoin node over Tor, where do we recommend running a LN node over Tor ?

Nowhere, *I* am the one recommending this.
Running both Bitcoin and Lightning nodes on clearnet automatically links them, making them easier to attack, whereas running Lightning on Tor does not.
Of course, they could still be linked by onchain transaction monitoring, but at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you.

On the other hand, you *could* run them on different public IP addresses, if you happen to have more than one; for those who do not even have a single public IP address there is no real choice if you want to let others to connect to you, Tor hidden service is the only Lightning-supported way to be accessible without a public IP.

(There are sections of the world where commodity "home" internet connections do not automatically get a public IP, and the privilege of getting one may be an additional cost; though of course if you have no real intent to help support either the Bitcoin or Lightning networks, you do not need a public IP anyway, and with IPv6 it becomes less and less likely that a randomly-chosen entity would be unlucky enough to not get a public IP.)

> > The victim *could* instead check that the absolute timelocks seem very far in the future relative to its own view of the current blockheight.
> I think you're right it's really dependent on CLTV_delta deployed on the path and time-dilation offset. The alternative you're proposing is a good one, but you shouldn't know where you're in the path and max CLTV is 2048 blocks IIRC.

Seeing an incoming payment that violates the max CLTV is a good indication you have been eclipsed.

On the other hand, if your Bitcoin node is eclipsed, then it seems likely your Lightning node is also eclipsed (if running over the same hardware) and you might not receive any indication over Lightning that you have been eclipsed anyway.

I suppose we need to identify just exactly *what* ways a node of either type can be eclipsed; it seems that mitigations that protect against one kind of eclipse will not work in general with other kinds of eclipse.

Regards,
ZmnSCPxj

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

[Aymeric Vitte]

Le 08/06/2020 à 06:56, ZmnSCPxj via bitcoin-dev a écrit :
> Running both Bitcoin and Lightning nodes on clearnet automatically links them, making them easier to attack, whereas running Lightning on Tor does not.
> Of course, they could still be linked by onchain transaction monitoring, but at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you.
Or makes it easier in fact, correcting what I said in my previous
answer, stating a "yes" for a mixed bitcoin and/or LN node in clearnet
and Tor, with or without different IPs, it's probably not difficult for
the Tor attacker to identify you (for example pinging the nodes with a
new received tx to see who has it in mempool)

Similar to "Deanonymizing the VPN peers"
https://github.com/Ayms/torrent-live, this is not public but the method
uses the clearnet/VPN "mixity" and unexpectedly the more you try to hide
the better you can get deanonymized

The conclusion is always the same: do not use the Tor network for
services it is not designed for

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

[ZmnSCPxj]

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

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

[Antoine Riard]

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