I thought it was very interesting that a PTL is equal to invalidating blocks that didn’t enforce FTL and/or obviously lied about their timestamp. I’m not disagreeing with anything you’ve said or advocating for anything other than your OP. I’m delving.
3 Likes
Are you referring to @murch solution?
Or to @zawy’s comment after that?
Can someone explain why the attack needs to alternate and can’t just use a constant low difficulty?
I suspect that would cause a mess. It could potentially introduce new attack vectors by messing with (node connections to) NTP servers. The current two hour margin is so wide you could set your computer clock with a sundial.
Block propagation throughout the whole network is probably in the order of seconds, but sometimes it seems take half minute: Mining Pool Behavior during Forks
Slowly validating blocks, poor internet connections and having to use Tor can all add many seconds to when you receive a block.
Later on:
With FTL meaning “Future Time Limit”. So do you mean just the existing rule that when we see a block it can’t be more than 2 hours in the future? Or do you mean the timestamp can’t be more than 2 hours ahead of that in the previous block?
It’s probably impossible to make testnet safe against all abuse, without making it permissioned. Otherwise we would have invented an actual alternative to proof-of-work. So in practice we should probably only:
- Fix attacks that actually happened and caused, or continue to cause, significant problems. E.g. the loppocapse blockstorms.
- Deployment things we want to see on mainnet, to see if they have bugs and to see if anyone comes up with an attack that wasn’t foreseen and could_be used on mainnet.
Let’s assume an attacker has already alternated one period of 4x difficulty increases with two periods of cumulative 1/16x difficulty decreases multiple times 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).
To keep difficulty the same, the attacker must set the last block in a period to two weeks later than the first block in the period. The cleanup/BIP94 anti-time-warp rule says the first block in the subsequent period must be about the same time (or later). That means, to keep difficulty the same in that subsequent period, the attacker must set the last block in that subsequent period to two weeks later than its first block (four weeks later than the first block of the first period). Eventually, a succession of these time increases will push the time used at retarget boundaries into the wall-time future (assuming the actual rate of block production exceeds 2,016 blocks/two weeks).
If an attacker instead uses minimal timestamps for all but the first block in one period (allowing difficulty to rise 4x) and then sets the final block in the subsequent period to 8 weeks later than the first block (lowering difficulty 4x), they can alternative this pattern indefinitely to produce up to 6 blocks per second without increasing the relative difference between any block time and wall time.
In other words, using alternation, if the two blocks that are set to 8 weeks later than their predecessor blocks still have a block time less than wall time + two hours, they’ll be accepted by full nodes. Not using alternation with the same 6 blocks/per second rate and the same starting time will quickly produce a chain that includes some block times far in the future, which will not be accepted until wall time catches up.
1 Like
The latter: we would not accept a block with a timestamp more than two hours in the future. (We have had “benign” gaps of more than two hours between blocks before.)
Miners aren’t supposed to agree on a source of time like NTP. The current FTL could be used in an attack if they did (for example to split the network hashrate).
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.
orphan rate = 1/1575 =~ 1-e^(-delay/600)
delay = - 600 * ln(1 - 1/1575)
Detecting selfish mining: If there’s a > 33% miner doing a minor selfish mining attack by withholding his found blocks for 1 or 2 seconds, it artificially increases the orphan rate which increases the estimate of the delays. You would have to know the propagation delay from some other method to see if it agrees with the orphan rate to detect the presence of a selfish miner. My +/- 10 s rule wouldn’t help if they’re holding blocks only 1 or 2 seconds. Another rule to help stop an attacker who’s causing tip races is for miners to choose the tip who’s arrival time is the closest to the timestamp, and change tips if he discovers the majority hashrate chose the other tip.
The newsletter mentioned monotonic timestamps might cause a problem if a timestamp targets the FTL. That would require finding a block less than 1 second after the “FTL block” and would be ignored for less than 1 second so I’m not sure what they have in mind. Does a block beyond the FTL have a penalty box where miners don’t work on it for some period of 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.
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…
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.
Ok, yeah, if sustained median delay is > 5 s, the -10 s rule would be a big problem (if there’s a 600 second “penalty box” for the block that broke the rule like I said). So I would drop that and keep + 10 s and “mine on the tip that has the most accurate timestamp”. For example if a miner sees an attacker’s block first and it has an old timestamp, the - 10 s rule isn’t there to prevent the miner from working on the attacker’s blocks. But if another block comes in close behind it (a sign of one of them being a selfish mining attack) but has a more accurate timestamp, then the miner should switch. This may also be what you would want if the 1st miner was a network delay instead of an attack because it shows the miner wasn’t well connected to your part of the mining network.
I meant that we should not accept a block whose timestamp exceeds our node’s wall clock time by more than 2h.