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