Oddbean

In my latest technical deep dive I ruminate upon a theoretical attack scenario that could be performed by an adversarial miner in order to give themselves a competitive advantage. https://blog.lopp.net/slow-block-validation-attacks/

Interesting article, thank you. Would it make sense for Core to prefer an easier to validate block of the same height if it is stuck on a hard to validate block? Essentially, for the node to be able to validate blocks of the same height in parallel under certain circumstances. That could change the game theory for the attacker.

Thanks for the response! I would have thought it was just policy and not consensus since the problematic block has not been validated in full yet. Given a valid new block header, my node will ignore any other header of the same height, even though it does not know that the first block received is fully valid, just that the header is. Assuming an implementation in which blocks of the same height can be validated in parallel, all this means is changing what the node does in the event of a tie from “first seen” to “first validated”. What am I missing?

Interesting analysis, but what I'm wondering and you didn't really develop is if it's technically possible to achieve that today and if yes what are the odds that this attack would be profitable to the attacker?

Very interesting, though I think there's an error in the formula for P(Attacker wins) given Attacker mined previous block. The correct formula is: 1 - (1 - Z)*exp(-Z*X/600) Consider C as the random variable for time of next block in the attack scenario (i.e., X seconds of Attacker mining solo, followed by all miners competing should process go past X seconds). Then we have: P(A wins) = P(A wins | C <= X)*P(C<=X) + P(A wins|C>X)*P(C>X) Which simplifies to above formula. The solid lines are the corrected values, and dashed are original: https://m.primal.net/Lfvz.png In particular, the needed delay to effectively double hash for slow blocks for the given scenarios changes to: 1% attacker - 10 minutes (instead of 7) 5% attacker - 11 minutes (instead of 8) 10% attacker - 12 minutes (instead of 9) 20% attacker - 14 minutes (instead of 12) Please, double-check my math, of course.

One additional thing that might be worth modeling a bit more is the actual impact of such an attack across a long sequence of blocks. Seems like some sort of Markov process with two states (Attacker mined previous block, and there is thus a delayed competition for the next block, or the next block is "fairly" mined). I'm not immediately seeing closed form solution, so ran a quick simulation and found the following: 1% Attacker and X=10 minutes: effective hash on delayed block = 2%, and over long chain unchanged at 1% 5% Attacker and X=11 minutes: effective hash on delayed block = 10.6%, and over long chain 5.6% 10% Attacker and X=12 minutes: effective hash on delayed block = 20.4%, and over long chain 11.3% 20% Attacker and X=14 minutes: effective hash on delayed block = 39.3%, and over long chain 25% Might also be interesting to see impact across difficulty adjustments (all other things being held constant), but haven't looked into that.