Is calendar time used in the Bitcoin network?

Anders

full member

Activity: 126

Merit: 100

Quote from: DannyHamilton on September 22, 2014, 03:48:29 PM

Quote from: Anders on September 21, 2014, 01:42:43 PM

Can a 55% attack on timestamps be done to mess up the blockchain?

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

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.

DannyHamilton

legendary

Activity: 3388

Merit: 4615

Quote from: Anders on September 22, 2014, 03:31:09 PM

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:

Quote from: Anders on September 21, 2014, 01:42:43 PM

Can a 55% attack on timestamps be done to mess up the blockchain?

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

Quote from: Anders on September 22, 2014, 11:16:57 AM

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.

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

Quote from: Anders on September 22, 2014, 11:34:57 AM

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

This is well covered in section 11 of the paper.

Anders

full member

Activity: 126

Merit: 100

Quote from: DannyHamilton on September 22, 2014, 03:09:33 PM

Quote from: Anders on September 22, 2014, 02:52:19 PM

- snip -
I think asking amateur questions can be helpful also for other people who are learning about Bitcoin.
- snip -

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.

DannyHamilton

legendary

Activity: 3388

Merit: 4615

Quote from: Anders on September 22, 2014, 02:52:19 PM

- snip -
I think asking amateur questions can be helpful also for other people who are learning about Bitcoin.
- snip -

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.

Anders

full member

Activity: 126

Merit: 100

Quote from: gmaxwell on September 22, 2014, 01:57:39 PM

Quote from: Anders on September 22, 2014, 12:36:49 PM

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?

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

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.

Anders

full member

Activity: 126

Merit: 100

Quote from: DannyHamilton on September 22, 2014, 01:18:14 PM

Quote from: Anders on September 22, 2014, 12:36:49 PM

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.

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

Quote

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

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.

gmaxwell

staff

Activity: 4172

Merit: 8419

Quote from: Anders on September 22, 2014, 12:36:49 PM

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?

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

DannyHamilton

legendary

Activity: 3388

Merit: 4615

Quote from: Anders on September 22, 2014, 12:36:49 PM

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?

Anders

full member

Activity: 126

Merit: 100

Quote from: DannyHamilton on September 22, 2014, 12:26:42 PM

Quote from: Anders on September 22, 2014, 11:34:57 AM

Quote from: deepceleron on September 22, 2014, 11:26:02 AM

Quote from: Anders on September 22, 2014, 11:16:57 AM

Quote from: theymos on September 22, 2014, 09:43:16 AM

Quote from: Anders on September 22, 2014, 01:50:18 AM

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

legendary

Activity: 3388

Merit: 4615

Quote from: Anders on September 22, 2014, 11:34:57 AM

Quote from: deepceleron on September 22, 2014, 11:26:02 AM

Quote from: Anders on September 22, 2014, 11:16:57 AM

Quote from: theymos on September 22, 2014, 09:43:16 AM

Quote from: Anders on September 22, 2014, 01:50:18 AM

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

full member

Activity: 126

Merit: 100

Quote from: deepceleron on September 22, 2014, 11:26:02 AM

Quote from: Anders on September 22, 2014, 11:16:57 AM

Quote from: theymos on September 22, 2014, 09:43:16 AM

Quote from: Anders on September 22, 2014, 01:50:18 AM

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?

deepceleron

legendary

Activity: 1512

Merit: 1028

Quote from: Anders on September 22, 2014, 11:16:57 AM

Quote from: theymos on September 22, 2014, 09:43:16 AM

Quote from: Anders on September 22, 2014, 01:50:18 AM

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

full member

Activity: 126

Merit: 100

Quote from: theymos on September 22, 2014, 09:43:16 AM

Quote from: Anders on September 22, 2014, 01:50:18 AM

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.

theymos

administrator

Activity: 5166

Merit: 12850

Quote from: Anders on September 22, 2014, 01:50:18 AM

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

deepceleron

legendary

Activity: 1512

Merit: 1028

Quote from: mmeijeri on September 21, 2014, 02:00:55 PM

Quote from: 2112 on September 21, 2014, 01:49:40 PM

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

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

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.

Anders

full member

Activity: 126

Merit: 100

Quote from: theymos on September 22, 2014, 12:13:55 AM

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.

theymos

administrator

Activity: 5166

Merit: 12850

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

mmeijeri

hero member

Activity: 714

Merit: 500

Martijn Meijering

Quote from: 2112 on September 21, 2014, 01:49:40 PM

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.

2112

legendary

Activity: 2128

Merit: 1065

Quote from: Anders on September 21, 2014, 01:42:43 PM

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

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.

Topic: Is calendar time used in the Bitcoin network? (Read 2001 times)