Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-30 Thread Bram Cohen via bitcoin-dev
This seems like a case where a distinction should be made between soft forks which are likely to cause non-upgraded miners to get orphaned and ones where they are. Of course in this case it's only 1/2016 of all blocks so it doesn't really matter, but it's worth thinking about the principle. In

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-29 Thread Zawy via bitcoin-dev
Rather than restricting every timestamp (or just the 2016*N+1 timestamps) to >= 1+ the previous timestamp as recorded on the blockchain, the difficulty calculation could have the same restriction but only in how the timestamps are used. I don't know about backwards compatibility. Either way, this

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-25 Thread Johnson Lau via bitcoin-dev
To determine the new difficulty, it is supposed to compare the timestamps of block (2016n - 1) with block (2016n - 2017). However, an off-by-one bug makes it compares with block (2016n - 2016) instead. A naive but perfect fix is to require every block (2016x) to have a timestamp not smaller

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-22 Thread Jorge Timón via bitcoin-dev
I only knew about ArtForz's fix, which isn't backwards compatible. https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev wrote: >

[bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-20 Thread Gregory Maxwell via bitcoin-dev
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