path: root/5f/d171d87782f232803af013fab9637c5cfc5135

Return-Path: <neiman.mail@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DAD2DE21
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 Jan 2018 10:52:22 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id 72so10959653iom.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>
References: <CACRYg-4ho-XGK3xUdQW-ny2BFs2O91BuendrxuVYBni4wHrRqw@mail.gmail.com>
	<CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>
From: Neiman <neiman.mail@gmail.com>
Date: Tue, 30 Jan 2018 11:52:21 +0100
Message-ID: <CACRYg-7dzUr++6yJVHnFvGuzXP6-hMEecfM-ttamqqoPkg52rw@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jan 29, 2018 at 10:40 PM, Tier Nolan via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D""></span><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.<br></d=
iv><div><br>I&#39;m comfortable with the 50%+ assumption regarding ledger m=
anipulation (double-spending, deletion of transactions etc.). I&#39;m much =
less comfortable with it regarding timestamps manipulation.<br><br></div><d=
iv>Consider the following situation:<br></div><div>(1) miners are selfish,<=
br></div><div>(2) miners have a financial incentive to be dishonest.<br><br=
></div><div>(1) is a common state on how miners function nowadays. (2) is t=
he case that interests us when coming to do this analysis.<br><br></div><di=
v>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.<br><br></div><div>In the case of timestamps manipulation, I do=
n&#39;t see any financial damage caused to miners. Timestamps manipulation =
(besides the 2016*n blocks) won&#39;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&#39;t see a justification for the 50%+ assumption he=
re.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div><b=
r></div><div>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.<br></div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>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. <br></div></div></blockquote><div><br>=
</div></span><div>If you are assuming that the miners are majority dishones=
t, then they can set the limit to anything as long as they don&#39;t move i=
t more than 2 hours into the future.</div><div><br></div><div>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.<br></div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" 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 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.<br><br>I&#39;m aware that this change re=
quires a hardfork, and won&#39;t happen any time soon. But does it make sen=
se to add it to a potential future hard fork?<br></div></div></blockquote><=
div><br></div></span>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.<br></div><div class=
=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"><div=
></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></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>

--001a114f362c3da5b20563fc2838--