path: root/74/6937cacd04fed7a2957f0339b17fbe6c5ad4e0

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CCFBEFD7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jan 2018 21:41:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com
	[74.125.82.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 307BE2F6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jan 2018 21:41:25 +0000 (UTC)
Received: by mail-ot0-f169.google.com with SMTP id r4so7972976oti.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jan 2018 13:41:25 -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=oXSqisKRJJvVValMcZ1gpAAwy5RJlyAD6ut4prMv3k8=;
	b=l+8o+t3ejo20lbtp9enw11Lia512En9vg+Brh57ufWMxnkOwx1vZQ8/Qes6KEev/CU
	ARtiOP0RUa5ExZUTWkKgbc3rBqj7RPnoeCPnb8bdfHLA3KupKQz/3jNSbUw5wC12D/5W
	mz3NNA8dXhQSH4taIMmcN0xbejsHI+Y62/USgMxpvSawovf5+KyZnCJIAaQ4umw0y/1N
	xunC3qhGaDhsa5qLxJIU6dONRt5o7EEwz6l8GEU8rHFBLo7ca42P5g/6b/xVMhJ1kBST
	FKcCKd9OaoQA3TnKbf6nhaMmzK9umoyhzLEdng+d+rPwLpKgIKFQAELUmJB8gZl3cyIL
	pvYA==
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=oXSqisKRJJvVValMcZ1gpAAwy5RJlyAD6ut4prMv3k8=;
	b=gKeTV39slMRxG+0kv08c4qGLzEAXR34MYF//e9G8DiqEFvoweqmroQiyeKikF4pqC9
	QG5Zj2GzPRkjAEp//lm9I3oEVS5HBdTrsiVEUJeGBRU04L9seFPFHzodp1euU3TptAWk
	D1p/EyMKkwxLCLf51Oj5d8Wzf8FU39ipud86DrMRPa8X1H0aQyPkzdOBAnvaHItnigp8
	Wub7ayA3tDEyEv0LfLP8im/lzEqpBreBWPJebuTQQTvCK6fh1IQUMhmjN2lCwn9zi4cc
	k9rwMiyTdiUBqWPRGoouO5mz/bu+ArCvUDM5xv5dgshLxFzuz2sfbukJyjAsetYYtCDc
	H70A==
X-Gm-Message-State: AKwxytdj7kPgU28LhZmLS8eksJiPCSn3DGY87xvg5eKN0t4m3QzavFf1
	JHaVz3tQ4Ux0Vraw5ML4HOMcs2GoTcuZxTkMzCo=
X-Google-Smtp-Source: AH8x226yocnfkKYr4+AS3/Xb+IMC0UvJ5v/oTNS6//BjIebWCBMQJC4pgtaleUqLbswQOX0FZo9IQp850PI9BcJkUSU=
X-Received: by 10.157.91.69 with SMTP id e5mr5288739otj.214.1517262084353;
	Mon, 29 Jan 2018 13:41:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.160.5 with HTTP; Mon, 29 Jan 2018 13:40:44 -0800 (PST)
In-Reply-To: <CACRYg-4ho-XGK3xUdQW-ny2BFs2O91BuendrxuVYBni4wHrRqw@mail.gmail.com>
References: <CACRYg-4ho-XGK3xUdQW-ny2BFs2O91BuendrxuVYBni4wHrRqw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Mon, 29 Jan 2018 21:40:44 +0000
Message-ID: <CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1c1fc691b2340563f11bb4"
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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 21:41:25 -0000

--94eb2c1c1fc691b2340563f11bb4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> *2.* Timestamps are not necessary to avoid double-spending. A simple
> ordering of blocks is sufficient, so exchanging timestamps with enumerati=
on
> would work double-spending wise. Permissioned consensus protocols, such a=
s
> hyperledger, indeed have no timestamps (in version 1.0).
>

The timestamps simply needs to be reasonably accurate.  Their main purpose
is to allow difficulty updates.

They can also be used to check that the node has caught up.


> It uses a simple average of block time in the last 2016 blocks. But such
> averages ignore any values besides the first and last one in the interval=
.
> Hence, if the difficulty is constant, the following sequence is valid fro=
m
> both the protocol and the miners incentives point of views:
>
>     1, 2, 3,=E2=80=A6., 2015, 1209600 (time of two weeks), 2017, 2018, 20=
19,=E2=80=A6.,
> 4031, 1209600*2, 4033, 4044, =E2=80=A6
>

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.

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 i=
t
> 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 timestamp=
s
> 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
>
>

--94eb2c1c1fc691b2340563f11bb4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><br><div><b>2.</b> Timestamps ar=
e not necessary to avoid double-spending. A simple ordering of blocks is su=
fficient, so exchanging timestamps with enumeration would work double-spend=
ing wise. Permissioned consensus protocols, such as hyperledger, indeed hav=
e no timestamps (in version 1.0).<br></div></div></blockquote><div><br></di=
v><div>The timestamps simply needs to be reasonably accurate.=C2=A0 Their m=
ain purpose is to allow difficulty updates.</div><div><br></div><div>They c=
an also be used to check that the node has caught up.<br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It uses a simple =
average of block time in the last 2016 blocks. But such averages ignore any=
 values besides the first and last one in the interval. Hence, if the diffi=
culty is constant, the following sequence is valid from both the protocol a=
nd the miners incentives point of views:<br><br>=C2=A0=C2=A0=C2=A0 1, 2, 3,=
=E2=80=A6., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,=E2=80=A6.,=
 4031, 1209600*2, 4033, 4044, =E2=80=A6<br></div></div></blockquote><div><b=
r></div><div>Much of Bitcoin operates on the assumption that a majority of =
miners are honest.=C2=A0 If 50%+ of miners set their timestamp reasonably a=
ccurately (say within 10 mins), then the actual timestamp will move forward=
 at the same rate as real time.<br></div><div><br></div><div>Dishonest mine=
rs could set their timestamp as low as possible, but the median would move =
foward if more than half of the timestamps move forward.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If we want to=
 be pedantic, the best lower bound for a block timestamp is the timestamp o=
f the block that closes the adjustment interval in which it resides. <br></=
div></div></blockquote><div><br></div><div>If you are assuming that the min=
ers are majority dishonest, then they can set the limit to anything as long=
 as they don&#39;t move it more than 2 hours into the future.</div><div><br=
></div><div>The miners could set their timestamps so that they increase 1 w=
eek fake time every 2 weeks real time and reject any blocks more than 2 hou=
rs ahead of their fake time.=C2=A0 The difficulty would settle so that one =
block occurs every 20 mins.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><br>Possible improvement:<br>--------------=
---------------<br>We may consider exchanging average with standard deviati=
on in the difficulty adjustment formula. It both better mirrors changes in =
the hash power along the interval, and disables the option to manipulate ti=
mestamps without affecting the difficulty.<br><br>I&#39;m aware that this c=
hange requires a hardfork, and won&#39;t happen any time soon. But does it =
make sense to add it to a potential future hard fork?<br></div></div></bloc=
kquote><div><br></div>For check locktime, the median of the last 11 blocks =
is used as an improved indicator of what the actual real time is.=C2=A0 Aga=
in, it assumes that a majority of the miners are honest.<br></div><div clas=
s=3D"gmail_quote">=C2=A0<blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>

--94eb2c1c1fc691b2340563f11bb4--