I only knew about ArtForz's fix, which isn't backwards compatible.


On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
bitcoin-dev mailing list

Reply via email to