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 DAD2DE21 for ; Tue, 30 Jan 2018 10:52:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3CED42F5 for ; Tue, 30 Jan 2018 10:52:22 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id 72so10959653iom.10 for ; Tue, 30 Jan 2018 02:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=i755Ix/xb3v24qhNy/yaKD/e/9PiI33VKwupDkeODI8=; b=qZdzGfc1jyyc0pzKXboJIsIzbAneAyD0aIrqvLGY9aME+RMkmOLEeTBZrg6XvWlukl wEsYmny5gAHp45SC/+bWuv7DCCh2D/lc8O512+UTHoQzbVNYyagWW3l9IREDkxYoAeLv yXR76NmovE6p+u2LzMJ629AEGb9Y1Msnw/nCRre8ujzg35dgz7btKXsFwKwQ6SVRaDcy 0Yonq9nUMG4HvhLMa2Mf7y86dvB7h8ksQlfk2CVwLU8xcUe8ssq7tXPHo1WEZ5D95NK2 6O+i3A+WPlRzlRq6oNZG84eJ/dXjosw7HfsUVEhzgt+uf6L0pPs7vHxHA//XCmYei1Zv sBGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=i755Ix/xb3v24qhNy/yaKD/e/9PiI33VKwupDkeODI8=; b=B8JBriZie9yUFOVHeHsWK6C/RgBJsR45L8Behhlt0mVDaQgLUTclaqmRLBZJi/aXbP oBqjb2d2s/YcnKabd+opiqSKDmKUfWE2KUHVHIXxdce3aHLToWvo+0h1BuWL2UPQdBTU KlzKJ+3OIJnbg7xx+nIPYmGf3ZzvuPrMPsk51a2KMz1C1vtrbud3sBogRacPNlmeRwDG rAh5JXOVIoNj2QCDEy1JtuWRODfOyVBeBLY342QbXXmdr5wNGJxotlPloQHth/96uWpf gGN3VvnwRfjO3CCpVutsQvk1pWW3AKFpn6Uwttpwt6ob2qdyhg8dznXwh8QmhhHQ0QAR 4JeQ== X-Gm-Message-State: AKwxytf0DhQawBm8VX4dx3uiNSNnFbSwDjsqwunXVN0OKlH34MAwZnPL aEw7aLn+IvM0APrl91LXLysLgN0+YcYgmNb97ZfX+w== X-Google-Smtp-Source: AH8x225Ja/VJena3NpAx8TNh/D7EF+ktvjiSlVDkjSP1frDVzkTSge/8KDl8WkxZyL6hka/ueGByVxTipiHi5QC63Cc= X-Received: by 10.107.190.67 with SMTP id o64mr29332083iof.286.1517309541588; Tue, 30 Jan 2018 02:52:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.77.141 with HTTP; Tue, 30 Jan 2018 02:52:21 -0800 (PST) In-Reply-To: References: From: Neiman Date: Tue, 30 Jan 2018 11:52:21 +0100 Message-ID: To: Tier Nolan , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114f362c3da5b20563fc2838" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Tue, 30 Jan 2018 15:23:31 +0000 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: Tue, 30 Jan 2018 10:52:23 -0000 --001a114f362c3da5b20563fc2838 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 29, 2018 at 10:40 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Much of Bitcoin operates on the assumption that a majority of miners are > honest. If 50%+ of miners set their timestamp reasonably accurately (say > within 10 mins), then the actual timestamp will move forward at the same > rate as real time. > Thank you for replying. I agree that under the 50%+ assumption, timestamps are reasonably accurately, but I fail to see a reason to make this assumption. I'm comfortable with the 50%+ assumption regarding ledger manipulation (double-spending, deletion of transactions etc.). I'm much less comfortable with it regarding timestamps manipulation. Consider the following situation: (1) miners are selfish, (2) miners have a financial incentive to be dishonest. (1) is a common state on how miners function nowadays. (2) is the case that interests us when coming to do this analysis. In the case of ledger manipulation, the 50%+ assumption is not because we assume that miners are good-hearted (this violates (1)). It is there due to an assumption that the financial damage to a miner would be bigger than the gain in (2). This happens since a ledge manipulation may cause miners to lose block rewards, and certainly will devaluate Bitcoin, an asset which they possess. In the case of timestamps manipulation, I don't see any financial damage caused to miners. Timestamps manipulation (besides the 2016*n blocks) won't harm the function of Bitcoin, and may even go undetected (it seems to me that the main blockchain explorers don't track it). I don't see a justification for the 50%+ assumption here. > > Dishonest miners could set their timestamp as low as possible, but the > median would move foward if more than half of the timestamps move forward. > > >> If we want to be pedantic, the best lower bound for a block timestamp is >> the timestamp of the block that closes the adjustment interval in which it >> resides. >> > > If you are assuming that the miners are majority dishonest, then they can > set the limit to anything as long as they don't move it more than 2 hours > into the future. > > The miners could set their timestamps so that they increase 1 week fake > time every 2 weeks real time and reject any blocks more than 2 hours ahead > of their fake time. The difficulty would settle so that one block occurs > every 20 mins. > > >> >> Possible improvement: >> ----------------------------- >> We may consider exchanging average with standard deviation in the >> difficulty adjustment formula. It both better mirrors changes in the hash >> power along the interval, and disables the option to manipulate timestamps >> without affecting the difficulty. >> >> I'm aware that this change requires a hardfork, and won't happen any time >> soon. But does it make sense to add it to a potential future hard fork? >> > > 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. > >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a114f362c3da5b20563fc2838 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 29, 2018 at 10:40 PM, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Much of Bitcoi= n operates on the assumption that a majority of miners are honest.=C2=A0 If= 50%+ of miners set their timestamp reasonably accurately (say within 10 mi= ns), then the actual timestamp will move forward at the same rate as real t= ime.

Thank you = for replying. I agree that under the 50%+ assumption, timestamps are reason= ably accurately, but I fail to see a reason to make this assumption.

I'm comfortable with the 50%+ assumption regarding ledger m= anipulation (double-spending, deletion of transactions etc.). I'm much = less comfortable with it regarding timestamps manipulation.

Consider the following situation:
(1) miners are selfish,<= br>
(2) miners have a financial incentive to be dishonest.
(1) is a common state on how miners function nowadays. (2) is t= he case that interests us when coming to do this analysis.

In the case of ledger manipulation, the 50%+ assumption is not because we= assume that miners are good-hearted (this violates (1)). It is there due t= o an assumption that the financial damage to a miner would be bigger than t= he gain in (2). This happens since a ledge manipulation may cause miners to= lose block rewards, and certainly will devaluate Bitcoin, an asset which t= hey possess.

In the case of timestamps manipulation, I do= n't see any financial damage caused to miners. Timestamps manipulation = (besides the 2016*n blocks) won't harm the function of Bitcoin, and may= even go undetected (it seems to me that the main blockchain explorers don&= #39;t track it). I don't see a justification for the 50%+ assumption he= re.
=C2=A0
Dishonest miners could set their timestamp as low as possible,= but the median would move foward if more than half of the timestamps move = forward.
=C2=A0
If we want to be pedantic, the best lower bou= nd for a block timestamp is the timestamp of the block that closes the adju= stment interval in which it resides.

=
If you are assuming that the miners are majority dishones= t, then they can set the limit to anything as long as they don't move i= t more than 2 hours into the future.

The miners co= uld set their timestamps so that they increase 1 week fake time every 2 wee= ks real time and reject any blocks more than 2 hours ahead of their fake ti= me.=C2=A0 The difficulty would settle so that one block occurs every 20 min= s.
=C2=A0

Possible improvement:
----------------------= -------
We may consider exchanging average with standard deviation in th= e difficulty adjustment formula. It both better mirrors changes in the hash= power along the interval, and disables the option to manipulate timestamps= without affecting the difficulty.

I'm aware that this change re= quires a hardfork, and won't happen any time soon. But does it make sen= se to add it to a potential future hard fork?
<= div>
For check locktime, the median of the last 11 blocks i= s used as an improved indicator of what the actual real time is.=C2=A0 Agai= n, it assumes that a majority of the miners are honest.
=C2=A0

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a114f362c3da5b20563fc2838--