Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B25301036 for ; Mon, 29 Jan 2018 21:54:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E5E51CE for ; Mon, 29 Jan 2018 21:54:24 +0000 (UTC) Received: by mail-vk0-f48.google.com with SMTP id z9so5515666vkd.5 for ; Mon, 29 Jan 2018 13:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=GOla6OsGnStk4gFqzsaiuxvc4eDbRXozci85iB44yLs=; b=LXN+MYij2VL5FYUN+YBi3s9jFhavqnppd95AGfsJSZP5T7nj2EpibRa4cx5cy7wCy4 f6xMdIv7g7ipNCyT1KC/DyDDh+ZphAAmXFkhjA//zTjFWfssDWa8V/fmXma0oSwzM21C BFlc+e4HaJOhZ6DwBXO4DYeGdBmykl6JNp688JSvo58FNDvZjxFB0ShOjUM05ZroOiQY 6SqZTkT8sXwnxK5r2dJoK0xVYtFMo8efPtR0qJQk85MfkxMltKz7cLPZG96GjPKlDGzi hgUtll5xmkSDNyXfLX08E51lroY0NQhgVs+zztW6umKr8EGod8b+3USP62IM7bIKTWsf PY8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=GOla6OsGnStk4gFqzsaiuxvc4eDbRXozci85iB44yLs=; b=bGbKwhKLCLV+QKgn881xPsNDxgdi2poavDN5QTi+vBUWf+ThejPVB22gH8V0MSURg3 mxriDn5Nn4VTjyt1iOlNYKf+iEcuf9zzyypwpFM3OiB3bKzmP9ayYpzbExW6SGqPZyFl ENvkZ4Mn44x09lDB8HVON/w7tcEacz/H4sbDIO0pBKHvjAAVWO6KeCL3mqV2VRZV5Dok 7skRIpfSEvOkCtNUCCVZTPeqI47Pid6Ywa9UG8rOIKA1Q+r09ijDrtwOVkSuKjmcjJ+3 QIsvDnR0zyUBgfvqWw/b95ci3WfhGmW4PADlk4Qx47easBOydH7HWvYZn0JOP3cAcZW7 502Q== X-Gm-Message-State: AKwxytfQ9PNZZ68Tf20/gzhzDNr6Me8jM/UyoZTyjVlKdKcQrl5U+9NT VHmTmGc0I/ZJd+csDAy8sT138KiJqopSbqEO/vc= X-Google-Smtp-Source: AH8x226nDeSFDLpziV7+RQQUMxC1nju0YJ7GW4ReWeK2hSkbjm8GS9Rv/sPZ2436zNxFonROkzdutfKWNob++erheNg= X-Received: by 10.31.0.136 with SMTP id 130mr4676416vka.15.1517262863691; Mon, 29 Jan 2018 13:54:23 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.78.155 with HTTP; Mon, 29 Jan 2018 13:54:23 -0800 (PST) In-Reply-To: References: From: Gregory Maxwell Date: Mon, 29 Jan 2018 21:54:23 +0000 X-Google-Sender-Auth: JbDPgZDajLj5fpN-2LzboUHOIac Message-ID: To: Tier Nolan , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Subject: Re: [bitcoin-dev] How accurate are the Bitcoin timestamps? 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: Mon, 29 Jan 2018 21:54:25 -0000 On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev wrote: > For check locktime, the median of the last 11 blocks is used as an improved > indicator of what the actual real time is. Again, it assumes that a > majority of the miners are honest. It would be more accurate to say that the median is not used for improved accuracy but to mitigate a consensus incompatibility: If the block's own timestamp were used for nlocktime and time based nlocks were common on the network each miner would maximize their fee income by setting the value as high as they could get away with. What concerned us wasn't so much that this would make the times less accurate (though it would) but rather that it would create an incentive for a runaway situation that could harm network stability (e.g. with all miners cranking times against the 2hr window, then creating pressure for miners to accept further and further in the future; each responding to his own local incentives). This incentive incompatibility could have been addressed e.g. by using the prior block's time, but since the protocol doesn't require times to be monotone (and for good reason!) the simple implementation of that wouldn't have been a soft-fork. The 11 block MTP worked out nicely because the protocol already required new times to be larger than that. The timestamps in Bitcoin aren't intended to be particularly accurate. They're used only for controlling the difficulty, and the adjustment window is large enough that there isn't much distortion that can be accomplished there. It's not clear to me that much better can really be done... if there were tighter time requirements in the protocol miners would address them by running NTP which as an _astounding_ lack of security in terms of how it is commonly deployed. As far as I know, I'm the only person whos ever mined blocks with their own stratum 1 time source. If times need to be accurate Bitcoin would need to use a rather different design (e.g. each block would commit to the observation time of the prior N blocks, and an iterative algorithm would solve for each blocks time and each miners local offset). IIRC open-timestamp calendar servers provide more precise time-stamping under the assumption that the calendar server is behaving correctly.