The ten minutes between blocks

[Walter Rothbard]

I've read the bitcoin whitepaper, and I understand the purpose of block generation to timestamp transactions.  What I don't understand is the need to regularize the block generation interval.  Why the attempt to space blocks out by a ten minute interval?  What would happen if blocks could be generated instantly?

[1715093559]

1715093559

[1715093559]

1715093559

[1715093559]

1715093559

[1715093559]

1715093559

[1715093559]

1715093559

[DeathAndTaxes]

Well if blocks could be generated instantly then they would be worthless.  Generating blocks is suppose to be tough.  It is a proof of work.  It requires the entire bitcoin global hashing power working on the same problem (quadrillions upon quadrillions of attemps) to find a solution.

The purpose of the block isn't just to timestamp the transaction.  It is to prevent a duplicate of the coins being spent (a double spend).  Since "good" miners will reject double spends it provides security in that if a tx is included in a block a replacement can't be accepted by the network unless some bad miners conspire to attack the network.

It doesn't have to be 10 minutes.  It could be 5 min or 30 min or 500 min.  10 was chosen to optimize two competing goals.  a) mimimize the frequency where two miners solve blocks at roughly the same time (and thus one block must become orphaned) and b) the speed of confirmations.

[klondike_bar]

just to expand n this question, why does it then take up to an hour or more at times to confirm "unconfirmed" transactions? shouldnt it take 10 minutes for each of the 6 needed confirmations?

(as mentioned, ive seen it take over an hour sometimes before it even gets from unconfirmed to 1/6 or 2/6 confirmations)

[DeathAndTaxes]

Three reasons
1) miners don't have to include your tx in the next block.  if you have no fee and the block is particularly large they may just leave it for some future block.  if your tx is particularly "spammy" (large numbers of low value inputs, bloating the size) it is more likely it will just be ignored.

2) blocks aren't once every 10 minutes.  The process is random (it has to be in a decentralized network).  On average the time between blocks is 10 minutes but individual times per block could be 1 minute or could be 120 minutes.

3) the network retargets only once ever 2014 blocks.  if network hashrate is declined since the last retarget the difficulty will be "too high" until the retarget and thus the average time between blocks will be slightly higher than 10 minutes.

[RyNinDaCleM]

Three reasons
1) miners don't have to include your tx in the next block.  if you have no fee and the block is particularly large they may just leave it for some future block.  if your tx is particularly "spammy" (large numbers of low value inputs, bloating the size) it is more likely it will just be ignored.

2) blocks aren't once every 10 minutes.  The process is random (it has to be in a decentralized network).  On average the time between blocks is 10 minutes but individual times per block could be 1 minute or could be 120 minutes.

3) the network retargets only once ever 2014 2016 blocks.  if network hashrate is declined since the last retarget the difficulty will be "too high" until the retarget and thus the average time between blocks will be slightly higher than 10 minutes.

FTFY!

[Walter Rothbard]

The purpose of the block isn't just to timestamp the transaction.  It is to prevent a duplicate of the coins being spent (a double spend).  Since "good" miners will reject double spends it provides security in that if a tx is included in a block a replacement can't be accepted by the network unless some bad miners conspire to attack the network.

Why is timestamping alone not sufficient to protect against double spending?

I get that the ten minutes is essentially arbitrary; i.e., there's nothing special about the number ten, other than trying to balance the amount of work that has to be redone as transactions arrive.

[DeathAndTaxes]

An attacker could trivially change the timestamp.  It is just a number. 

Say I pay you and it gets included in a block with a timestamp of X.  What would prevent me from just making another block with an earlier timestamp where I didn't pay you.  Absolutely nothing.  Of course anyone could do that to any transaction and the coins would have no value at all.  The proof of work makes it have a real economic cost to attempt such revising of history and unless you have more than all the "good guys" combined the odds are stacked against you being successful.

[Walter Rothbard]

An attacker could trivially change the timestamp.  It is just a number. 

Say I pay you and it gets included in a block with a timestamp of X.  What would prevent me from just making another block with an earlier timestamp where I didn't pay you.  Absolutely nothing.  Of course anyone could do that to any transaction and the coins would have no value at all.  The proof of work makes it have a real economic cost to attempt such revising of history and unless you have more than all the "good guys" combined the odds are stacked against you being successful.

Each block has a pointer to the previous block, though, so how could this attack work?  After you pay me in the block with timestamp X, you could forge another block with timestamp X-5 in which the money went somewhere else, but a traversal of the blockchain from the block with timestamp X would show that your new forged block was not in the chain, right?

What am I missing?  I am speculating that it has something to do with chain forks and orphan blocks....

[DeathAndTaxes]

The network needs to be in consensus.  You can't have a situation where for a given height there are two different blocks.  If the attacker creates alternate blocks they would also be equally valid just different.

Example:
block 123
block 124A - block with tx where I pay you (includes hash of block123)
block 124B - block with tx where I double spend you (also includes hash of block 123)

now the network is split.  part of the network believes 124A is the "real block124" and part of the network believes 124B is the "real block124".  this can't remain forever otherwise the two portions of the network will fork off onto seperate incompatible sub networks.

How does bitcoin resolve this?  miners will build upon the longest chain.  So eventually block 125 will be solved.  If 125 contains the blockhash for 124A then 124B gets orphaned and 124A becomes "the real 124".   If 125 contains the blockhash for 124B then 124A gets orphaned.

Now if all that matters is a timestamp a block has no real value as unit of security/work.   I wouldn't just create a new 124A I would create a new 124A, 125, 126, 127, 128 ....  ten billion more block ....

tada the chain w/ my tx is in the longest so you lose.  Of course you would be doing the same thing as would everyone on the network.   

Bitcoin is based at is CORE around of concept of PROOF OF WORK.   The fact that a tx is in a block (or buried x blocks deep in the blockchain) is PROOF of a certain amount of work.   If the block is trivially produced then it is proof of NOTHING.  There is no certainty in transactions, no "guarantee" the transactions can't be reversed (easily).

[Maged]

Each block has a pointer to the previous block, though, so how could this attack work?  After you pay me in the block with timestamp X, you could forge another block with timestamp X-5 in which the money went somewhere else, but a traversal of the blockchain from the block with timestamp X would show that your new forged block was not in the chain, right?

What am I missing?  I am speculating that it has something to do with chain forks and orphan blocks....

I think I get what you're saying. You're saying that because everyone already saw a certain block, it's impossible to forge a new one. However, it can easily be the case that because of network latency between peers, different node won't be in the same state at the same time. It is possible for an attacker to tell two different nodes about different versions of the same block and they won't hear of the other conflicting block until later. As DeathAndTaxes explained, this conflict of state is eventually resolved through proof-of-work.

Additionally, because nodes go online and offline in the network as they please, any system that depends on what was heard first without some way to resolve conflicts would totally collapse even if you had some way to reduce latency between all peers to zero.

[Nagato]

I've read the bitcoin whitepaper, and I understand the purpose of block generation to timestamp transactions.  What I don't understand is the need to regularize the block generation interval.  Why the attempt to space blocks out by a ten minute interval?  What would happen if blocks could be generated instantly?

The other reason is that a valid block becomes a permanent addition to the blockchain, meaning consumption of network bandwidth and disk space for all nodes today and tomorrow.Generating too many too fast would put an increased burden on network connections for all nodes.
And as D&T pointed out, it increases the probability of orphan chains(2 blocks competing to be the next block).