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

[Matt Corallo]

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
>