From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E1A7255 for ; Sat, 18 May 2019 17:40:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 101C15E4 for ; Sat, 18 May 2019 17:40:27 +0000 (UTC) Received: by mail-vs1-f46.google.com with SMTP id q64so6663806vsd.1 for ; Sat, 18 May 2019 10:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wLUgULmEKOvSkLfbTU0VJa03Qwk/6197mOH6cR6XHY4=; b=H+H1tLiTR/dl2gq26j+ljoaU5F3eR1iE8Wr37iQdIG7rHNPPYkz3os9q/xnHrGOrpM IU2ufcNYKXXc4YlxTXRGRYgikgDVS1bkZkWFTVw8ANbvee6JwpRfzkN5pl6VrBqJ1dcZ oQgeRl8EViXK8oi4QBk0VAcEQ5HQNQ1srNPZDp+2Vrwqz/exyJS3kWbsfr7UWBKu/dLn FNTeBmEpQo7Ze2SMC4hYGTPtLSTfo35kJRqr14U25TJAK40+2Y1PuysEScHBsEfTn/Fl usQdfnkymW+0DXBYQQnZc9hw/iTBsYhx4YpkTiJos6k8IOBvT6k++z2Dv0Wkp4SdCAVM jI2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wLUgULmEKOvSkLfbTU0VJa03Qwk/6197mOH6cR6XHY4=; b=EBT9OCug1CaYXcl5ez/9pGanCM8Yoh1t+Qds/6/CQvSLLEvUHAUiu2QiZZ+UBnO16C KzQW6ezFL+W8xWSpQ599uLnqSp8SMfTfbRdEbQf4rkRD0F1vxtK7SVWH8kFD9CXy/Zt1 8x8oIt6cHrPVXWLTPK7JUszKokW+I0haQIhqk8mxYOWXtDDZAGhAVv33T651mcspIhLA V052JFJrjyOnFAQdkVECUVQj9KZXOkilOD0sJFUuHor9e6L9sspZ6CNYTtgb2JIyKIVe 2TE1BnzYDQuGraxBJSl5ukdmPDanVTUK3pKXyJfOrlaLvLJYJtZ2iZbzE2ZfYMhQp3t2 bNvw== X-Gm-Message-State: APjAAAWcXkXiVY+789o+qCL8ILtuzY+oA31LPPIPjfW43kCOfb7NpLYY s8LMWJJ++b+kdNYDddHLy8Yn/QJcoDnRFf1JYvAIAMaL X-Google-Smtp-Source: APXvYqx3pC/LeHT5zcm6XzI34r77P3hKtlTXG/8zruWeYzwkE2h9zsGssWZVPPpvN8yybYeX1BiP7BREuJxQfmKKGD8= X-Received: by 2002:a67:fd93:: with SMTP id k19mr17149843vsq.45.1558201226851; Sat, 18 May 2019 10:40:26 -0700 (PDT) MIME-Version: 1.0 From: Zawy Date: Sat, 18 May 2019 13:40:16 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 18 May 2019 17:51:17 +0000 Subject: [bitcoin-dev] Code not following proof of security X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2019 17:40:28 -0000 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.