Code not following proof of security



Summary:

In order to ensure Proof of Work (POW) security, the code for cryptocurrency mining should reflect a proof of security. If MAX_FUTURE_BLOCK_TIME in chain.h is set smaller than DEFAULT_MAX_TIME_ADJUSTMENT in timedata.h, it can lead to a 33% Sybil attack on the nodes, which undermines POW security. This occurs because blocks with accurate timestamps would be rejected, allowing various attacks. POW security requires clock synchronization, but using median of network time for it is a consensus mechanism that is subject to Byzantine attacks. Therefore, POW requires an absolute bound on time 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. Many cryptocurrencies have reduced MAX_FUTURE_BLOCK_TIME in order to have faster responding difficulty algorithms. However, this can allow for manipulation of difficulty, and thus MAX_FUTURE_BLOCK_TIME should be a function of the size of the difficulty window for proof of security. It is important to ensure that the code reflects proof of security, as "unintended consequences due to how disparate code interacts" can result from not following this principle. The fail-safe uses node operators as the oracle, who can all approximately agree as to what time it is without asking each other. Cryptonote appears to have done away with network time without ill effect.


Updated on: 2023-06-13T18:52:45.163410+00:00