Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

From: Neiman <neiman.mail@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?
Date: Tue, 30 Jan 2018 11:52:21 +0100	[thread overview]
Message-ID: <CACRYg-7dzUr++6yJVHnFvGuzXP6-hMEecfM-ttamqqoPkg52rw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 5300 bytes --]