public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Getting around to fixing the timewarp attack.
@ 2018-08-29  9:54 Zawy
  0 siblings, 0 replies; 5+ messages in thread
From: Zawy @ 2018-08-29  9:54 UTC (permalink / raw)
  To: 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 would also prevent the powLimit
attack that is also capable of getting "unlimited" blocks in less than
4 weeks of > 50% selfish mining.  LTC, BCH, and LTC fixed to the
"Zeitgeist" or "timewarp" attack on GeistGeld in 2011 described by
Artforz in different ways, but all are still vulnerable by the
powLimit attack that I described here:
https://github.com/zawy12/difficulty-algorithms/issues/30

Other solutions may not prevent this other attack.


^ permalink raw reply	[flat|nested] 5+ messages in thread
* [bitcoin-dev] Getting around to fixing the timewarp attack.
@ 2018-08-20 20:14 Gregory Maxwell
  2018-08-22 13:48 ` Jorge Timón
  2018-08-24  9:35 ` Johnson Lau
  0 siblings, 2 replies; 5+ messages in thread
From: Gregory Maxwell @ 2018-08-20 20:14 UTC (permalink / raw)
  To: 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 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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-08-30 20:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-29  9:54 [bitcoin-dev] Getting around to fixing the timewarp attack Zawy
  -- strict thread matches above, loose matches on Subject: below --
2018-08-20 20:14 Gregory Maxwell
2018-08-22 13:48 ` Jorge Timón
2018-08-24  9:35 ` Johnson Lau
2018-08-30 20:55   ` Bram Cohen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox