Zawy’s Alternating Timestamp Attack

[sjors]

@harding

to bring difficulty down to a level at which they can produce six blocks per second (the maximum rate that can be sustained without increasing MTP faster than wall time).

I hadn’t thought about the fact that for someone with 50% hash power there is such a thing as too low a difficulty. This is because the MTP rule creates an effective maximum block rate, beyond which difficulty is pushed up. So if before the attack they produce a block every 1200 seconds (10 minutes / 50%), to reach that maximum rate of 6 blocks per second, requires a difficulty decrease of 6 * 1200 = 7200 = 2 * 16 * 16 * 16.

And so I guess you want to either oscillate above that, or keep it constant at some low value.

@murch

The latter: we would not accept a block with a timestamp more than two hours in the future.

Now I’m confused. When you say “the future” I think of wall clock time, but “the latter” refers to block timestamps. I assume you meant block timestamps?

Keep in mind that (at least in Stratum v2) an ASIC may have a job queued up for the next block. They would then receive a NewPrevHash message. So ideally you should be able to decide the timestamp of block N + 1 before you know the timestamp of block N. Alternatively we’d have to modify the message to send both the prevhash and the last block timestamp.

So I would prefer a constraint on timestamps that don’t refer to the exact previous block. Though the current timewarp mitigation has the same issue…

@zawy

I get 380 ms as a delay that’s between the median and mean of the propagation delay. I used the data from this paper to see the exponential CDF might serve as the estimate from the orphan rate. This page shows about 1 orphan per 1575 blocks in the past year.

But the current network is probably not under any kind of major attack. Any proposed mechanism has to work under much worse circumstances than today.