As the focus for Bitcoin Cash protocol development is shifting to the November upgrade we should look at the difficulty adjustment algorithm (DAA).

The current DAA, that doesn’t work so well, is a simple filter and it has been suggested by various people that an exponential decay filter would work better. A little investigation shows that when blocks have so called negative duration, this causes problems for such a solution, though.

So when the timestamps from block N is higher than the one after it. This is legal on the blockchain and it turns out that this would be a problem in a DAA which uses the exponential decay algorithm.

So this raises the question: how often does this actually happen? How often is the timestamp of a block before the timestamp of the block it extends?

I decided to write a little Javascript app to find out. FloweeJS provides a nice framework for searches of all types. The Flowee.Job.FetchBlockHeader is what we want as the header contains the timestamp of a block.

On finishing of the search we can find the result as a new property in the form of block$height with the various header properties as members. You can see this result being used in the code snipped: let header = this[block${height}];

function timeForBlock(height, prevTime) {
    Flowee.search({
        jobs: [{
            value: height,
            type: Flowee.Job.FetchBlockHeader,
        }],
        onFinished: function() {
            let header = this[block${height}];
            if (typeof header === 'undefined')
                process.exit();
            if (header.time < prevTime)
                console.log("Block " + height + " is before prev by "
                  + (prevTime - header.time) + "s");
            timeForBlock(height + 1, header.time);
        }
    });
}

var Flowee = require('bindings')('flowee');
Flowee.connect().then(function() { timeForBlock(550000, 0); })

Results

Block negative times happen quite regularly. 483 times since block 550000, so for that 85405 span that gives us once every 177 blocks. So on average once every 30 hours.

The vast majority of the values are single-digit seconds with some greater than 60 seconds and a really rare set a couple of years ago (height 561678) that is over half an hour before the previous block.

When we think about this a bit longer, this makes sense. Miners can create blocks with almost any timestamp. The rule is that it can’t be more than 2 hours in the future, though. So there is a limit there.

Then imagine a miner making a block that is an hour in the future, the next miner currently can just go back to the current time, creating a negative block-interval, but the resulting time is more likely to be closer to ‘on-time’ then when the rules forces the miner to lie, which would be the case if he had to pick a time later then the previous one which was already late.

Graphical result

Below is a histogram (thanks fly to emergent reasons who is clearly better at spreadsheets than I am).

As you can see, the vast majority of the negative times are small. The various columns to the right are practically invisible. The max is about 2200 seconds negative, and that is from many years ago.

Conclusion: Miners do not currently manipulate the times of their blocks to any unreasonable extend.

For the values below 500 seconds we can confirm this by zooming in.

Raw output here.
JavaScript here