[Lightning-dev] Time-Dilation Attacks on Offchain Protocols

Antoine Riard antoine.riard at gmail.com
Mon Dec 16 20:12:12 UTC 2019


> It seems pretty easy to me to detect the difference between the normal
> case (Alice's chaintip is old but she's still successfully downloading>
> blocks) and the pathological case (Alice's chaintip is old and she's
> unable to obtain more recent blocks).

I think if alarm is implemented at the validation level it's not going to
be reliable due to IBD. While connecting and validating headers, it's okay
to
process headers timestamp that's hours or days old. Current
IsInitialBlockDownload
logic returns false if tip is less than a day old. By slowing blocks
announcement I
could pin you indefinitely in IBD and alarms are not going to be triggered.
The issue
being than the comparison point can be manipulated by the attacker.

Now, if alarm is implemented at the net_processing level, I think that's
something like
CheckForStaleTipAndEvictPeers is doable but tricky. If you're past
headers-sync from one
peer and best block header announced by a peer is too way in the past,
disconnect it. Still,
you can't be sure because maybe this node was buggy or its connection was
faulty, so you need to
repeat this few times and if all these peers announce block in the past
there something is wrong
and raise an alarm. But it seems hard to have detection without doing
active peer rotation and this
may have bad side effects on connectivity..

You want a reliable detection mechanism because if it's cheaply triggered
you now have DoS attack
vectors on the LN layer, like delaying blocks knowing it's going to trigger
alarm and than a LN processing
node will close its channels.  You want scoping the issue beyond "something
is wrong" (and like you mention
there is also the edge case of a legit several hours delay) that's why
fetching headers thanks to some
redundant communication channel seems to me better.

> To a point, transaction censorship just looks a failure to pay a
> sufficient feerate---so a node will probably fee bump a
> commitment/penalty transaction a few times before it starts to panic.

I don't do the assumption of hashrate-attackers but yes that's interesting
than you may combine
with some mempool tricks to optimize the attack.

Antoine

Le lun. 16 déc. 2019 à 10:29, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :

> Right, I kinda agree here in the sense that there are things that very
> significantly help mitigate the issue, but a) I'm not aware of any
> clients implementing it (and the equivalent mitigations in Bitcoin Core
> are targeted at a different class of issue, and are not sufficient
> here), and b) its somewhat unclear what the "emergency action" would be.
> Even if you implement detection, figuring out how to do a fallback is
> nontrivial, especially if you are concerned with user privacy.
>
> Matt
>
> On 12/16/19 9:10 AM, David A. Harding wrote:
> > On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:
> >> If well executed, attacks described stay stealth until it's too late
> >> to react.
> >
> > I suspect the attacks you described are pretty easy to detect (assuming
> > block relay is significantly delayed) by simply comparing the time of
> > the latest block header to real time.  If the difference is too large,
> > then an emergency action should be taken.[1]
> >
> > You mention IBD as confounding this strategy, but I don't think that's
> > the case.  Compare the normal case to the pathological case:
> >
> > - Normal: when Alice is requesting blocks from honest nodes because
> >   she's far behind, those nodes are telling her their current block
> >   height and are promptly serving any blocks she requests.
> >
> > - Pathological: when Alice is requesting blocks from a eclipse attacker,
> >   those dishonest nodes are telling her she's already at the chain tip
> >   even though the latest block they serve her has a header timestamp
> >   that's hours or days old.  (Alternatively, they're reporting the
> >   latest block height but refusing to serve her blocks/headers past a
> >   certain point in the past.)
> >
> > It seems pretty easy to me to detect the difference between the normal
> > case (Alice's chaintip is old but she's still successfully downloading
> > blocks) and the pathological case (Alice's chaintip is old and she's
> > unable to obtain more recent blocks).
> >
> > A possibly optimal attack strategy would be to combine
> > commitment/penalty transaction censorship with plausible block delays.
> > To a point, transaction censorship just looks a failure to pay a
> > sufficient feerate---so a node will probably fee bump a
> > commitment/penalty transaction a few times before it starts to panic.
> > Also to a point, a delay of up to several hours[2] just looks like
> > regular stochastic block production.  By using both deceits in the same
> > attack to the maximum possible degree without triggering an alarm, an
> > attacker can maximum their chance of stealing funds.
> >
> > -Dave
> >
> > [1] There is an interesting case where a large miner or cartel of miners
> >     could deliberately trigger a false positive of block delay
> >     protection by manipulating Median Time Past (MTP) to allow them to
> >     set their header nTime fields to values from hours or days ago.  I
> >     don't believe the fix for the time warp proposed in the consensus
> >     cleanup soft fork fixes this, since it only directly affects the
> >     first block in a new difficulty period (preventing difficulty gaming
> >     but not header time gaming).  This problem is partly mitigated by
> >     miners keeping MTP far in the past being unable to claim fees from
> >     recent time locked transactions (see BIP113), though I'm not sure
> >     how many transactions are actually using nLockTime-as-a-time (LN and
> >     anti-fee sniping use it as a height).
> >
> > [2] If we suddenly lose half of Bitcoin's hashrate so that the average
> >     time between blocks is 20 minutes, there's a once-in-a-century
> >     chance of a block taking more than 310 minutes to produce:
> >
> >         1 / (exp(-310/20) * 144 * 365)
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191216/db2fc00a/attachment-0001.html>


More information about the Lightning-dev mailing list