Oddbean

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.