From antoine.riard at gmail.com Mon Dec 16 20:12:12 2019 From: antoine.riard at gmail.com (Antoine Riard) Date: Mon, 16 Dec 2019 15:12:12 -0500 Subject: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols In-Reply-To: <46b5288e-21f5-9be9-e203-5bf4ec516cee@mattcorallo.com> References: <20191214185419.7ghkxtc4ntcyzlzk@ganymede> <20191216091018.xgtoqpd7tuuip5py@ganymede> <46b5288e-21f5-9be9-e203-5bf4ec516cee@mattcorallo.com> Message-ID: > 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 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: