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

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

bitcoin-dev mailing list

Reply via email to