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 enumeration would work double-spending wise. Permissioned consensus protocols, such as 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 from both the protocol and the miners incentives point of views:

    1, 2, 3,…., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,…., 4031, 1209600*2, 4033, 4044, …

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