Interesting!
And this is why I like the empirical "block box" approach. I don't care initially what the mechanism is. I try to find a simple model that explains the effect, and then, later, ask what that mechanism might be.
But now why would the "latency of the mining process" depend on the size of the previous block? That doesn't make sense to me, but we just showed empirically that F2Pool is indeed more likely to produce an empty block when the previous block is large.
It wouldn't expect the miner latency part to be size dependant: the miner can't even tell how big the prior block was. I expect your function relating them to have a big constant term in it! (thats why I asked if you tried other regression approaches. )And this is why I like the empirical "block box" approach. I don't care initially what the mechanism is. I try to find a simple model that explains the effect, and then, later, ask what that mechanism might be.
But now why would the "latency of the mining process" depend on the size of the previous block? That doesn't make sense to me, but we just showed empirically that F2Pool is indeed more likely to produce an empty block when the previous block is large.
I suppose there may be some dependance that is introduced by virtue of what percentage of the miners got the dummy work. Would be pretty interesting to try to seperate that.
Another trap of empirical analysis in this kind of discussion is that we can only measure how the system is-- but then we use that to project the future; e.g. say we didn't have ECDSA caching today, you might then measure that it was taking >2 minutes to verify a maximum size block... and yet 100 lines of code and that cost vanishes; which is bad news if you were counting on it to maintain incentives.
Miners can't tell as soon as a block header is published, but they can tell once they get the block, according to Peters analysis bigger blocks received take longer to
ftfy