FloweeJS; finding negative block times.

10 289
Avatar for TomZ
Written by
4 years ago

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 values (and copy/pastable code): https://gitlab.com/snippets/1977420

10
$ 14.74
$ 13.37 from @molecular
$ 0.50 from @emergent_reasons
$ 0.50 from @unitedstatian
+ 4
Avatar for TomZ
Written by
4 years ago

Comments

Perfect

$ 0.00
4 years ago

Interesting. A small suggestion: we have code syntax highlighting, so if you insert a code block - it will be highlighted, no need to insert as an image :) Would it help if an exponential decay algorithm just think of negative time blocks as 1 second blocks? i.e. we assume the minimal block time to be 1s?

$ 0.10
4 years ago

Oh, I tried different approaches and was unhappy with the rendering. I must have done something wrong. Is there a tutorial ?

$ 0.00
4 years ago

Sure, https://read.cash/@Read.Cash/how-to-use-the-editor-at-readcash-e2df60aa#code-blocks Just put three backticks or click the code block button

$ 0.00
4 years ago

That's just beautiful! Thank you!

$ 0.00
4 years ago

This article is very important to the BCH ecosystem. I would have enjoyed it better, but there are some technical things that didn't clear to me. Are those things programming or what(not histograms)? I always like to learn if you can teach me. Thanks.

$ 0.00
4 years ago

Any chance of getting a histogram for the results?

$ 0.00
4 years ago

Thanks for the interesting concept. It's such a high profile writing with graphical explanation. Telling a section of cryptic times. Well done

$ 0.00
4 years ago

Who needs spreadsheets when you have pandas.

$ 0.00
4 years ago

The current DAA uses medians of 3 consecutive blocks (with some implementation mess). Perhaps that same principle could be used for the exponential algorithm too (minus the implementation mess of course), at the cost of adjustments kicking in one block later if times are monotonic. Does a median of 3 get rid of most of the negative block times you found?

$ 0.00
4 years ago