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 should be coded as
DEFAULT_MAX_TIME_ADJUSTMENT = MAX_FUTURE_BLOCK_TIME / 2 (or sufficiently commented) otherwise future developers could make a change that hurts security. "Unintended consequences due to how disparate code interacts" is the result of code not following a proof of security. I came across this while trying to "derive" POW security from within Lamport's 1982 framework. The problem is that POW security requires clock synchronization. But using median of network time for it is a consensus mechanism that is subject to Byzantine attacks. So POW requires an absolute bound on time (enforced by an oracle) that is at least as stringent as the allowed timestamp variation. The rule to revert to node time if network time is >70 minutes off is the real bound that honest nodes can impose unilaterally, limiting the potential damage of consensus (if MAX_FUTURE_BLOCK_TIME is not too small). This fail-safe uses node operators as the oracle, who can all approximately agree as to what time it is without asking each other. A >50% Sybil attack on nodes fails because an honest new node joining can unilaterally reject the chain if the current timestamp is not realistic. Cryptonote appears to have done away with network time without ill effect. The only other option to "the node operator is the oracle" is to assume all internal clocks have a max drift, but this would disconnect timestamps from real time to the extent of that drift (if I'm reading Halpern, etc 1984 IBM correctly). I'm assuming Mike Hearn was wrong in saying the centralization of NTP (or GPS) is acceptable: https://bitcointalk.org/index.php?topic=10241.msg148084#msg148084 This affects coins who reduced MAX_FUTURE_BLOCK_TIME without either removing the time consensus mechanism or reducing the DEFAULT_MAX_TIME_ADJUSTMENT. Many have done this in order to have faster responding difficulty algorithms, otherwise a large MAX_FUTURE_BLOCK_TIME allows a sizable manipulation of difficulty. Therefore, MAX_FUTURE_BLOCK_TIME should itself should be a function of the size of the difficulty window for proof of security (instead of a constant). I suspect more constants = less proof of security. For example MFBT = WindowTimespan / 10 would limit timestamp manipulation to 10% per window. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
