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

2020-06-11 Thread Antoine Riard via bitcoin-dev
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  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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-08 Thread Aymeric Vitte via bitcoin-dev

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-07 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-07 Thread Antoine Riard via bitcoin-dev
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 

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

2020-06-05 Thread Aymeric Vitte via bitcoin-dev
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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-05 Thread Aymeric Vitte via bitcoin-dev

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
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