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

From: Antoine Riard <antoine.riard@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Gleb Naumenko <naumenko.gs@gmail•com>
Subject: Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Date: Sun, 7 Jun 2020 18:31:54 -0400	[thread overview]
Message-ID: <CALZpt+FF0e1wSY5mBY-rVLQu4EGAjQefK9EQDCiExqMvKVc5UQ@mail.gmail.com> (raw)
In-Reply-To: <2phhD75B8ww3hFQ8Do039wAIlW8EVOjUeiedm-JtIek-TEnVocYSx-untchGrO3VoRLoPzinVAG95UN1yR3CadNWBJGSu19vJpFJ_yN-wZY=@protonmail.com>

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