MIME-Version: 1.0
From: Zawy <wordsgalore@gmail.com>
Date: Sat, 18 May 2019 13:40:16 -0400
Message-ID: <CADtTMv=H1rqfspx4=r+TDqxWVOXRO5yROzTuo0go6vtpevEJDQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [bitcoin-dev] Code not following proof of security
Precedence: list

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.