If MAX_FUTURE_BLOCK_TIME in chain.h is set smaller than
DEFAULT_MAX_TIME_ADJUSTMENT in timedata.h, the POW security can be
undermined by a 33% Sybil attack on the nodes. Blocks with accurate
timestamps would be rejected which allows various attacks. Code should
reflect a proof of security, so it sh
It's possible to let the difficulty linearly drop as the solvetime
goes beyond some limit (credit AS). If the limit is greater than any
delay in the past it could be backwards-compatible.
A simple daily-rolling average DA like BCH is probably the best option
if a faster DA is ever needed.
As a po
The 51% problem is deep. Any discussion of a solution to it should
begin with a link to an article that shows a profound discovery has
been made. Selfish mining prevention and pollution should be on
bitcoin-discussion, but it appears that list is not active.
The problem with Andrew's idea below is
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
