ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-08 📝 Original message:Good morning Antoine, > > ...
📅 Original date posted:2020-06-08
📝 Original message: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
📝 Original message: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