Bitcoin Forum

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?

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)

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.

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.

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?

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? :D

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.

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.

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.

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

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:

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?

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?

Double spending is absolutely and completely precluded in a blockchain. Everyone always checks for double spending already, it's one of the rules.  I suspect you've missed this.

(I'd really recommend some quiet time trying to understand the system instead of so many posts.)

If two or more transactions are competing, then they can all be rejected I would guess.


Yes! My proposal is a distributed hash table (DHT) where each coin has a unique id and is locked into the DHT with a digital signature. I don't know yet if it would work though.

Yes, I need to learn more about the Bitcoin protocol. The problem is that there are so many details. The Satoshi white paper is only a very high level description and the real Bitcoin implementation is much more complicated with all the details. Plus I think asking amateur questions can be helpful also for other people who are learning about Bitcoin. But ok, I need to check the details better beforehand I agree.

Then please ask your questions in the "Beginner & Help" section instead of the "Development & Technical Discussion" section.

Have you actually read the whitepaper?

Because, while it might be a "high level description", it answers the questions that you are asking here.

Yes, I have read this document: https://bitcoin.org/bitcoin.pdf

I took a look at it again and it doesn't mention how calendar time is handled. At least I couldn't find any information about it.

True.  That particular question is not answered in the paper. And was answered very well in this thread.

The questions that are less well though out are:


Clearly not, since as can be seen in that paper, the time has no effect on the ordering of blocks in the blockchain.  According to the paper, the blocks themselves in the blockchain are "the timestamp" that is used to order transactions (a block that occurs higher in the chain is "later" than a block that occurs lower in the chain regardless of any calendar time stored in the block).


Since it had already been made clear that nodes will only accept a timestamp "if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours.", then it should be clear that a >50% attack can't change the timestamps significantly. The paper specifically states that nodes "reject invalid blocks by refusing to work on them." and that "Any needed rules and incentives can be enforced with this consensus mechanism."  Furthermore, it states that "An attacker can only try to change one of his own transactions to take back money he recently spent".


This is well covered in section 11 of the paper.

I think I understand it now. It's easier for the nodes to check calendar time, since that's a global value. The transactions on the other hand can be spread out on different nodes. Calendar time is only needed for determining the next difficulty.