Thanks Kjj,
If we assume (given sufficiently numerous non-malicious nodes ignoring rare 2, 3.. block reorgs) that forks occur during the latent time between a new block is broadcast and receipt, then average weighted latency is much longer than I would have guessed:
Latency/GenerationTime = 1/284
Latency = 2.11 seconds
I also assume that waste is not only due to reorg but occurs with all but one node during latent time after every block generation. So my suggested ten seconds is in the ballpark of 50% efficiency. I wouldn't have expected that. Thanks for the lesson.
Topic: Rational for specifically ten minute block generation rate (Read 1927 times)
The block explorer reorg log is showing 15 reorgs in the last 8538 blocks. We generally assume that about half the forks lead to a reorganization in a given node*, so that is about 30 forks. That is about one fork per 284 blocks, which is close to my estimate of 300 blocks per fork.
So, I would expect a two block fork every 90 thousand blocks or so, maybe every 80 thousand using the block explorer data. That is every year and a half, by the way. A three block fork should show up under honest circumstances about once every 450 to 500 years.
A shorter block time target would probably lead to more frequent forks, measured in blocks per fork, but it isn't obvious what the function would be. Halving the block time target, for example, would lead to probably more than double the forks per year. It could probably be simulated, but hasn't that I know of.
* The best predictor of which block will win in a fork is the fraction of the network seeing that block. If we assume that the distribution is more or less random, they should both average out to around 50%.
So, I would expect a two block fork every 90 thousand blocks or so, maybe every 80 thousand using the block explorer data. That is every year and a half, by the way. A three block fork should show up under honest circumstances about once every 450 to 500 years.
A shorter block time target would probably lead to more frequent forks, measured in blocks per fork, but it isn't obvious what the function would be. Halving the block time target, for example, would lead to probably more than double the forks per year. It could probably be simulated, but hasn't that I know of.
* The best predictor of which block will win in a fork is the fraction of the network seeing that block. If we assume that the distribution is more or less random, they should both average out to around 50%.
Thank you all. I've just read the FAQ. It's interesting to note that the FAQ suggests reading the bitcoin.pdf for more details, which I have done more than once, and see no further rational except the RAM limits posted earlier. The latency I thunked up meself. From the FAQ:
Kudos as always to Satoshi for predicting variables quite wisely before bootstrapping the entire block chain. After two years, do we have any statistics on the frequency and duration of chain splits, the network latency between the majority of miners? Ten minutes does seem like a fine choice, though I would guess now with data we could calculate the optimal choice and how that optimal changes over time.
Quote
Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. If that made no sense to you, don't worry. Reading the technical paper should make things clearer.
Kudos as always to Satoshi for predicting variables quite wisely before bootstrapping the entire block chain. After two years, do we have any statistics on the frequency and duration of chain splits, the network latency between the majority of miners? Ten minutes does seem like a fine choice, though I would guess now with data we could calculate the optimal choice and how that optimal changes over time.
Netrin, I suggest reading the FAQ at some point 
https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F
https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F
Satoshi always acknowledged that it was a trade-off.
If you make the blocks too frequent, you get more cases where two blocks are generated at nearly the same time. Due to network propagation delays, this can cause temporary splits in the block chain.
On the other hand, if you make blocks too infrequent, it takes too long for a transaction to become essentially irrevocable.
If you make the blocks too frequent, you get more cases where two blocks are generated at nearly the same time. Due to network propagation delays, this can cause temporary splits in the block chain.
On the other hand, if you make blocks too infrequent, it takes too long for a transaction to become essentially irrevocable.
The official rationale is that 10 minutes is a round number.
There is a trade off between traffic/storage/etc and confirmation latency. As far as I know, there is no way to objectively measure the goodness or badness of either of those, so there is no optimal choice. 10 minutes seems to be "pretty good" so far.
There is a trade off between traffic/storage/etc and confirmation latency. As far as I know, there is no way to objectively measure the goodness or badness of either of those, so there is no optimal choice. 10 minutes seems to be "pretty good" so far.
Why was a ~ten minute block generation rate chosen rather than say ten seconds?
Perhaps someone can point me to an extant article or discussion regarding this topic. I would like to read previous arguments. In Satoshi's paper I only see one reference (when discussing disk space).
Is that the crux of it - to reduce the size of the entire block chain stored in RAM? Or is network latency considered - minimizing the number of competing longest block chains by assuming ten minutes is sufficient time to propagate a single block to the entire network? Perhaps there are other (psychological, economical) arguments?
Perhaps someone can point me to an extant article or discussion regarding this topic. I would like to read previous arguments. In Satoshi's paper I only see one reference (when discussing disk space).
Quote
A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.
Is that the crux of it - to reduce the size of the entire block chain stored in RAM? Or is network latency considered - minimizing the number of competing longest block chains by assuming ten minutes is sufficient time to propagate a single block to the entire network? Perhaps there are other (psychological, economical) arguments?
Jump to: