Exploring a method to reduce the risk of block storms on Bitcoin testnet
Discussion
Background on Bitcoin testnet block storms by #[2]: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
By the way, #[3] , you say that a fix would require a hard fork. Is that a common belief?
A simple soft fork* would be to require that the last block in a difficulty adjustment period has a timestamp no greater than 20 minutes after the previous block.
__
* A soft fork in the sense that it only restricts consensus rules. Miners that don't implement the change might get their block invalidated by this. But such a block would be a difficulty-1 block, so no big deal.
That should work for the happy path, though I bet it would introduce other edge cases.
These are the concerns and edge cases I can think of regarding a soft fork to set a maximum timestamp limit on block 2015:
## Can a maximum timestamp requirement of prev timestamp + 20 min conflict with the minimum timestamp requirement of prev mediantime + 1 sec, making it impossible to mine a new block on top of the latest one?
No, because prev mediantime can not be greater than prev timestamp. The mediantime of a block is the median of the timestamps of that block and the 10 before it. Because that block itself must have a timestamp greater than the median of the 11 blocks before it, it must have a timestamp greater than that of at least 6 of those blocks. It follows that it must have a timestamp greater than at least 5 of the 10 blocks before it. Thus, its timestamp can only be set so low as to also define the block's own mediantime.
## Could non-upgraded miners run off in a chain split?
Yes, if they start a block storm. But they would reorg and join the upgraded chain as soon as the upgraded chain finds block 2015. This is because the non-upgraded chain would all consist of difficulty-1 blocks for the next 2017 blocks (and then increasing by no more than 4x for every difficulty period after that). That is, the blocks do not make a heavy chain. Even if the non-upgraded chain had more hashing power in theory, they would be limited by the rate of new blocks having to be sent across the network.
## Could the chain stop at block 2014 for hours because all ASIC miners left?
This is a possibility. Is it worse than a block storm, though? Not everyone has their own ASIC miner, but renting some ASIC time shouldn't be too hard or expensive (should cost no more than about 40 cents per expected block at the current difficulty and BTC price).
The method I'm exploring is to try to force the mining of the last block in a difficulty adjustment to happen at full difficulty for as long as possible, to maximize the chance that a full-difficulty block is found before difficulty drops to 1.
Last block storm was triggered on Oct 31, it might take a few months to see if this method is effective.
The triggering block, at height 2378879, seems to have been _deliberately_ set 20 minutes ahead of actual time. Its timestamp is exactly 20 min 1 sec after the previous block, and 20 min 3 sec _after_ the _following_ block.
Deliberate attacks might still succeed in triggering block storms.
A preventive block was successfully mined at height 2421214. The two blocks that followed had an interval of 31 minutes between them.
If those blocks had been mined at the same rate without the preventive block, there would have been another block storm! #bitcoin #testnet #[0]