<div dir="ltr"><div dir="ltr">> It seems pretty easy to me to detect the difference between the normal<br>> case (Alice's chaintip is old but she's still successfully downloading> <br>> blocks) and the pathological case (Alice's chaintip is old and she's<br>> unable to obtain more recent blocks).<br></div><div dir="ltr"><br></div><div>I think if alarm is implemented at the validation level it's not going to</div><div>be reliable due to IBD. While connecting and validating headers, it's okay to</div><div>process headers timestamp that's hours or days old. Current IsInitialBlockDownload</div><div>logic returns false if tip is less than a day old. By slowing blocks announcement I</div><div>could pin you indefinitely in IBD and alarms are not going to be triggered. The issue <br></div><div>being than the comparison point can be manipulated by the attacker. <br></div><div><br></div><div>Now, if alarm is implemented at the net_processing level, I think that's something like <br></div><div>CheckForStaleTipAndEvictPeers is doable but tricky. If you're past headers-sync from one</div><div>peer and best block header announced by a peer is too way in the past, disconnect it. Still,</div><div>you can't be sure because maybe this node was buggy or its connection was faulty, so you need to</div><div>repeat this few times and if all these peers announce block in the past there something is wrong</div><div>and raise an alarm. But it seems hard to have detection without doing active peer rotation and this</div><div>may have bad side effects on connectivity..<br><br></div><div>You want a reliable detection mechanism because if it's cheaply triggered you now have DoS attack</div><div>vectors on the LN layer, like delaying blocks knowing it's going to trigger alarm and than a LN processing</div><div>node will close its channels. You want scoping the issue beyond "something is wrong" (and like you mention</div><div>there is also the edge case of a legit several hours delay) that's why fetching headers thanks to some</div><div>redundant communication channel seems to me better.<br><br>> To a point, transaction censorship just looks a failure to pay a<br>> sufficient feerate---so a node will probably fee bump a<br>> commitment/penalty transaction a few times before it starts to panic.<br></div><div><br></div><div>I don't do the assumption of hashrate-attackers but yes that's interesting than you may combine</div><div>with some mempool tricks to optimize the attack. <br></div><div><br></div><div>Antoine<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 16 déc. 2019 à 10:29, Matt Corallo <<a href="mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Right, I kinda agree here in the sense that there are things that very<br>
significantly help mitigate the issue, but a) I'm not aware of any<br>
clients implementing it (and the equivalent mitigations in Bitcoin Core<br>
are targeted at a different class of issue, and are not sufficient<br>
here), and b) its somewhat unclear what the "emergency action" would be.<br>
Even if you implement detection, figuring out how to do a fallback is<br>
nontrivial, especially if you are concerned with user privacy.<br>
<br>
Matt<br>
<br>
On 12/16/19 9:10 AM, David A. Harding wrote:<br>
> On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:<br>
>> If well executed, attacks described stay stealth until it's too late<br>
>> to react. <br>
> <br>
> I suspect the attacks you described are pretty easy to detect (assuming<br>
> block relay is significantly delayed) by simply comparing the time of<br>
> the latest block header to real time. If the difference is too large,<br>
> then an emergency action should be taken.[1]<br>
> <br>
> You mention IBD as confounding this strategy, but I don't think that's<br>
> the case. Compare the normal case to the pathological case:<br>
> <br>
> - Normal: when Alice is requesting blocks from honest nodes because<br>
> she's far behind, those nodes are telling her their current block<br>
> height and are promptly serving any blocks she requests.<br>
> <br>
> - Pathological: when Alice is requesting blocks from a eclipse attacker,<br>
> those dishonest nodes are telling her she's already at the chain tip<br>
> even though the latest block they serve her has a header timestamp<br>
> that's hours or days old. (Alternatively, they're reporting the<br>
> latest block height but refusing to serve her blocks/headers past a<br>
> certain point in the past.)<br>
> <br>
> It seems pretty easy to me to detect the difference between the normal<br>
> case (Alice's chaintip is old but she's still successfully downloading<br>
> blocks) and the pathological case (Alice's chaintip is old and she's<br>
> unable to obtain more recent blocks).<br>
> <br>
> A possibly optimal attack strategy would be to combine<br>
> commitment/penalty transaction censorship with plausible block delays.<br>
> To a point, transaction censorship just looks a failure to pay a<br>
> sufficient feerate---so a node will probably fee bump a<br>
> commitment/penalty transaction a few times before it starts to panic.<br>
> Also to a point, a delay of up to several hours[2] just looks like<br>
> regular stochastic block production. By using both deceits in the same<br>
> attack to the maximum possible degree without triggering an alarm, an<br>
> attacker can maximum their chance of stealing funds.<br>
> <br>
> -Dave<br>
> <br>
> [1] There is an interesting case where a large miner or cartel of miners<br>
> could deliberately trigger a false positive of block delay<br>
> protection by manipulating Median Time Past (MTP) to allow them to<br>
> set their header nTime fields to values from hours or days ago. I<br>
> don't believe the fix for the time warp proposed in the consensus<br>
> cleanup soft fork fixes this, since it only directly affects the<br>
> first block in a new difficulty period (preventing difficulty gaming<br>
> but not header time gaming). This problem is partly mitigated by<br>
> miners keeping MTP far in the past being unable to claim fees from<br>
> recent time locked transactions (see BIP113), though I'm not sure<br>
> how many transactions are actually using nLockTime-as-a-time (LN and<br>
> anti-fee sniping use it as a height).<br>
> <br>
> [2] If we suddenly lose half of Bitcoin's hashrate so that the average<br>
> time between blocks is 20 minutes, there's a once-in-a-century<br>
> chance of a block taking more than 310 minutes to produce:<br>
> <br>
> 1 / (exp(-310/20) * 144 * 365)<br>
> <br>
> <br>
> _______________________________________________<br>
> Lightning-dev mailing list<br>
> <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
> <br>
</blockquote></div>