Is calendar time used in the Bitcoin network?

[Anders]

I read that: "The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks." -- https://en.bitcoin.it/wiki/Difficulty

(In reality it's at the moment actually 2015 blocks, but anyway.)

Based on time? Calendar time? Global time server? Consensus calendar time algorithm among nodes?

[amaclin]

every block has timestamp which is checked by some rules
so it is easy to calculate time diff between last block and block #(last-2016)

[Rannasha]

I read that: "The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks." -- https://en.bitcoin.it/wiki/Difficulty

(In reality it's at the moment actually 2015 blocks, but anyway.)

Based on time? Calendar time? Global time server? Consensus calendar time algorithm among nodes?

Miners include a timestamp in each block. This is used to determine the size of the difficulty adjustment. The timestamps included are just the local clocks of the miners machines. These are not accurate, but that's okay. The protocol specifies a relatively large maximum tolerance on these timestamps, which means it can happen that block N has a later timestamp than block N+1.

[Anders]

every block has timestamp which is checked by some rules
so it is easy to calculate time diff between last block and block #(last-2016)

So the miner that gets the reward sets the timestamp? Seems a bit shaky, but I guess the nodes do some kind of calendar time check to see if the timestamp seems reasonable.

[Anders]

I read that: "The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks." -- https://en.bitcoin.it/wiki/Difficulty

(In reality it's at the moment actually 2015 blocks, but anyway.)

Based on time? Calendar time? Global time server? Consensus calendar time algorithm among nodes?

Miners include a timestamp in each block. This is used to determine the size of the difficulty adjustment. The timestamps included are just the local clocks of the miners machines. These are not accurate, but that's okay. The protocol specifies a relatively large maximum tolerance on these timestamps, which means it can happen that block N has a later timestamp than block N+1.

Yes, I guessed that the miner getting the reward used a local clock. But yikes, can the calendar timestamps be put into the blockchain in wrong order? It works because the change of difficulty is on average every two weeks, but what if that time period is reduced in later versions of the code?

[2112]

The "current time" on the Bitcoin network is a median of the time of last 11 blocks.

Note the cute duality: median of 11 is a 6th element in a sorted array, so "time hasn't moved forward until median time of 11 last blocks has increased " and "money transfer not confirmed until 6 confirmations are seen" are mathematically dual.

[Anders]

The "current time" on the Bitcoin network is a median of the time of last 11 blocks.

Note the cute duality: median of 11 is a 6th element in a sorted array, so "time hasn't moved forward until median time of 11 last blocks has increased " and "money transfer not confirmed until 6 confirmations are seen" are mathematically dual.

But what are the rules for calendar time check of the individual blocks? Can a 55% attack on timestamps be done to mess up the blockchain?

[2112]

But what are the rules for calendar time check of the individual blocks? Can a 55% attack on timestamps be done to mess up the blockchain?

Yes. The only defense is a sheer expense of doing that attack. Also note that attacking time over a significant period would also attack the difficulty, so the stupid attacker (speeding up the time) will actually attack itself through the difficulty increase.

[mmeijeri]

Yes. The only defense is a sheer expense of doing that attack. Also note that attacking time over a significant period would also attack the difficulty, so the stupid attacker (speeding up the time) will actually attack itself through the difficulty increase.

There's some sort of additional sanity check, a valid block cannot have a timestamp that is off by more than two hours from the median of the last ten blocks or something like that.

[theymos]

https://en.bitcoin.it/wiki/Block_timestamp

[Anders]

https://en.bitcoin.it/wiki/Block_timestamp

"A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours."

This part is a potential problem: "A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, ..."

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

[Dabs]

Ideally, all miners would be synchronized to the actual real world time according to most time servers. Does not make sense to not use the correct time. The bitcoin blockchain is also being used indirectly as a time stamp server, but as noted, the time is only accurate to a few hours.

[deepceleron]

Yes. The only defense is a sheer expense of doing that attack. Also note that attacking time over a significant period would also attack the difficulty, so the stupid attacker (speeding up the time) will actually attack itself through the difficulty increase.

There's some sort of additional sanity check, a valid block cannot have a timestamp that is off by more than two hours from the median of the last ten blocks or something like that.

I can verify that I have verified that this code is there and it works.

Code:

    // Check timestamp
    if (block.GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return state.Invalid(error("CheckBlock() : block timestamp too far in the future"),
                             REJECT_INVALID, "time-too-new");

You can mine a testnet block with your computer clock set 119 minutes into the future, but if you were to timestamp a block over two hours ahead, the network (which all have a similar opinion of the time) will reject the block (as in ignore the block and no further blocks will be built on it), at least until enough time has elapsed that the block can be retransmitted after it does comply with network time rules. This is just based on each miner's clock, which are not allowed to be off from network time consensus by more than five minutes without a warning.

The network consensus time is very accurate. I run NTP and never get more than nTimeOffset = -2  (+0 minutes) in the logs.

Since there is very little latitude in block timestamps that will be accepted, this does not give the miner much room in fudging a timestamp on the retarget block - two weeks (336 hours) +/- 1 hour. Here you can see the debug.log of retargeting being done:

Code:

2014-09-14 23:03:37   nActualTimespan = 1112235  before bounds
2014-09-14 23:03:37 GetNextWorkRequired RETARGET
2014-09-14 23:03:37 nTargetTimespan = 1209600    nActualTimespan = 1112235
2014-09-14 23:03:37 Before: 182815ee  00000000000000002815ee000000000000000000000000000000000000000000
2014-09-14 23:03:37 After:  1824dbe9  000000000000000024dbe917e45e45e45e45e45e45e45e45e45e45e45e45e45e

[theymos]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

[Anders]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

But wouldn't the majority of nodes accept the false timestamps in a 55% attack? Hmm... And that would mean that they can even set timestamps backwards in time.

[deepceleron]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

But wouldn't the majority of nodes accept the false timestamps in a 55% attack? Hmm... And that would mean that they can even set timestamps backwards in time.

If the 51% miner created a blockchain with rules that no other Bitcoin accepted, then they would basically be creating their own blockchain fork that the rest of the network ignores.

[Anders]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

But wouldn't the majority of nodes accept the false timestamps in a 55% attack? Hmm... And that would mean that they can even set timestamps backwards in time.

If the 51% miner created a blockchain with rules that no other Bitcoin accepted, then they would basically be creating their own blockchain fork that the rest of the network ignores.

Then how is double spending possible in a 51% attack?

[DannyHamilton]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

But wouldn't the majority of nodes accept the false timestamps in a 55% attack? Hmm... And that would mean that they can even set timestamps backwards in time.

If the 51% miner created a blockchain with rules that no other Bitcoin accepted, then they would basically be creating their own blockchain fork that the rest of the network ignores.

Then how is double spending possible in a 51% attack?

Because the type of "double spending" that's possible with a 51% attack doesn't create rules that no other bitcoin node accepts.  Instead, it takes advantage of the consensus system to force bitcoin to do exactly what it always does, but lets the attacker choose the consensus.

[Anders]

This means that if for example the Chinese government wants to mess with bitcoin because they see it as a threat to their own currency, the yuan, then they could do a 55% attack and set the timestamps to year 2106 when the 32-bit timestamp wraps around to zero.

That'd be greater than the network-adjusted time plus 2 hours...

But wouldn't the majority of nodes accept the false timestamps in a 55% attack? Hmm... And that would mean that they can even set timestamps backwards in time.

If the 51% miner created a blockchain with rules that no other Bitcoin accepted, then they would basically be creating their own blockchain fork that the rest of the network ignores.

Then how is double spending possible in a 51% attack?

Because the type of "double spending" that's possible with a 51% attack doesn't create rules that no other bitcoin node accepts.  Instead, it takes advantage of the consensus system to force bitcoin to do exactly what it always does, but lets the attacker choose the consensus.

Does that mean that if the Bitcoin protocol is changed so that all nodes check for double spending, then that would prevent a 51% attack?

[DannyHamilton]

Does that mean that if the Bitcoin protocol is changed so that all nodes check for double spending, then that would prevent a 51% attack?

If two different nodes receive two different competing transactions, how would they decide which transaction is the "real" one, and which is the "double spend"?

Right now the solution that bitcoin created was a consensus system where proof-of-work is used to establish the order of the transactions.

If a single entity can accumulate more proof-of-work than the entire rest of the world combined, (more than 50%), then they are able to choose the order of the transactions.

Have you discovered a better distributed consensus system than proof-of-work?