Since 2012 (IIRC) we've known that Bitcoin's non-overlapping difficulty calculation was vulnerable to gaming with inaccurate timestamps to massively increase the rate of block production beyond the system's intentional design. It can be fixed with a soft-fork that further constraints block timestamps, and a couple of proposals have been floated along these lines.
I put a demonstration of timewarp early in the testnet3 chain to also let people test mitigations against that. It pegs the difficulty way down and then churned out blocks at the maximum rate that the median time protocol rule allows. I, and I assume others, haven't put a big priority into fixing this vulnerability because it requires a majority hashrate and could easily be blocked if someone started using it. But there haven't been too many other network consensus rules going on right now, and I believe at least several of the proposals suggested are fully compatible with existing behaviour and only trigger in the presence of exceptional circumstances-- e.g. a timewarp attack. So the risk of deploying these mitigations would be minimal. Before I dust off my old fix and perhaps prematurely cause fixation on a particular approach, I thought it would be useful to ask the list if anyone else was aware of a favourite backwards compatible timewarp fix proposal they wanted to point out. Cheers. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
