Topic: Reasons to keep 10 min target blocktime? - page 2. (Read 4384 times)

I am concerned that a possible practical improvement is getting lost in the theory discussion.  With lots of factors to balance, there is a risk that any big change would lead to problems.  No one wants that.  But from what I understand, changing the target interval to 5 minutes would be safe.  Max block size would be shrunk to 500KB, coins issued per block would be cut in half.

Lets take your arguments gmaxwell, and look at them in the context of this specific proposal.


So the blocktime would be at 5 min in this case.  The orphan rate would be higher, but I'm guessing it would it rise by more than 5% or 10%.  And lets remember, the orphan rate is under 1% of all blocks, so the actual percentage of orphans would change from lets say  0.80% to something like 0.85%.  I'm just making these numbers up, so let me know if you disagree or have better estimates of the actual values.  I don't know to much about the convergence concept.  I would guess that 500KB blocks every 5 minutes still be well within the margin of safety though.


Good to know.  Lets not do that!  I don't think anyone would think 5 minutes is stupidly low (unless they were stupid?).


This may be a good point.  I don't know enough about how the headers work, but I'll try.  Empty-block headers are about 80 bytes.  If every block thus far had been empty, we would have ~20MB would of block headers since the genesis.  That number would be ~40MB if it had been 5 mins from the start.  A question: would the header-of-a-100-transaction-block + the header-of-an-empty-block be the same size as the two 50-transaction headers combined?  If that is true, than the added header 'overhead' costs would seem to be reasonable, basically an additional 80 bytes every 10 minutes over what we generate now.


Seems like Meni is taking you up on the security side.  Statistics aside, lets not forget the importance of that first confirmation!  I've met dozens of people in coffee shops helping them to get some bitcoins.  In purely human terms, there is a big difference between 5 and 10 minutes.  5 minutes is fast food, 10 is not.  You expect putting gas in a car to take 5 minutes - 10 would be a drag.  5 minutes just feels a lot faster than 10.  And since that first confirmation is way, way (maybe 100x?) more secure than an unconfirmed one, everything happening twice as fast would be very convenient for the bitcoin community as it is today.  I agree that in the future there will be lots of solutions to these issues, but to get there from here we need to keep people happy and things convenient so that the community lives on.

Of course, if Meni is right, and I think he is, then you can multiply that savings if you need more confirmations.  The current security provided by three confirmations (30 mins) could be replaced by four confirmations at 5 minutes (20 mins), and time savings will be afforded at any desired level of security.


It's good there are options, but this is a very technical solution.  Don't forget we want to make bitcoin better for even minimally technical users, so therefore it is not an argument against 5 minute blocktime.


The distribution curve doesn't change shape, but the timescale underneath it will be shrunk by a factor of two!  Again, transactions where two people initiate the transaction and then wait it out, but that 1, 2 or 6 blocks.  Whatever your number is, you will be waiting half as long on average.  Adjusting to keep the security level the same would not result in a 50% times savings, but maybe 30%.  Meni will tell you the exact amount.


No one wants to wait longer.  This is 99% a technical issue, and if the core dev team gives it's blessing, people will be very excited.  Why not propose raising it to 20 minutes and see if there is a similar level of excitement.  I tend to think we need a hard fork to prove to ourselves that we are dynamic community and can handle the challenge.  With core dev support, consensus will easily be over 95%.

Under the assumption that orphaning isn't an issue, with a lower mean block time you need to wait less on average for a given level of security.

For example, let's say that with either 5 min or 10 min mean time, orphaning isn't an issue. Let's say also that you want a 10%-hashrate attacker to have less than 2% chance of successfully double spending, so you wait for 3 confirms.

If 10 min is the time constant, you have to wait 30 mins on average. If it's 5 min, you have to wait 15 mins. This is an advantage of a lower time constant, as suggested by the OP.

The behavior of the security function is different in different regions of parameters so an extreme case does not prove anything about a more typical case. With infinitesimal blocks the focus is on total compute power spent as you say, but with more typical block times the focus is on the statistical properties of an atemporal random walk.

Of course with a network difficulty of 1 you'd never converge, but this defies the assumption that "you are slow enough that orphaning isn't a major consideration".


If miners use software that verifies that blocks it finds are reported by the pool, and the pool publishes the headers of its shares, then no time is needed to verify the pool is working honestly.

I'm speaking specifically about confirm count without regard to latency.  If what I was saying wasn't true, miners publishing all their diff 1 shares would suddenly make Bitcoin a million times more secure.

That's false, which is the main point I was trying to explain in https://bitcoil.co.il/Doublespend.pdf.

Isnt the argumentation at least a little flawed?

Because shorter block times also mean shorter blocks.

Should make no difference, if you have for 10 minute block time, 1 time long validation time,
while for 1 minute blocks, 10 time short validation time. The sum is the same.

I'm not so sure there— as I mentioned we've observed propagation times in Bitcoin that would have made litecoin catch fire with its inter-block gap… Difference is that Bitcoin is bigger and has more transactions, though perhaps the performance improvements made to 0.8+ have removed this risk.

Without completely discarding a bit of luck, I lean towards "very thoughtful". We don't know how many chains he/they started to test different sets of parameters until finally accepting and announcing the current one.

And if that isn't enough, bitcoin has a bunch of magic numbers in it.  Most of them seem to have been picked because they were round numbers that fit into a broad range of values that were "good enough".

Consider that the average block time could have been chosen anywhere from 1 second to 86400 seconds.  1 second is clearly too short for network convergence.  86400 seconds is clearly too long for effective commerce.  Between those two extremes is a broad band that is "good enough" for both, as well as regions that are questionable for one or the other.  Would 60 seconds be too short?  Probably.  120?  Maybe.  Would 3600 seconds be too long?  Probably.  1800?  Maybe.

And the various magic numbers interact.  For example, the block time and the subsidy function come together to set the generation curve.

Satoshi was either very lucky, or very thoughtful.  The numbers he picked all came together to give us a workable system.  The success of the system gives a very strong (quasi)anthropic argument: we are here discussion the merits of various key values because the system works well enough for us to care about it.  If he had chosen poorly, bitcoin would not have taken off.

And finally, consider litecoin.  Litecoin has a 150 second block time.  This number appears to still be large enough that convergence isn't a huge problem.  But litecoin does not appear to be used for commerce other than buying and selling litecoins, so a shorter time seems to provide no commercial benefits.  If the long block time was holding us back, the world would have beaten a path to litecoin.

In addition to the excellent points made by gmaxwell:

(5) you really want to make sure that your coin can work and converge through Tor. That includes:

(5a) plain Tor: 3 hops

(5b) hidden service Tor: 6 hops + onion address lookup time

Edit: If you still aren't convinced please reread the discussion with Lolcust about Geist Geld with 15 seconds of interblock time.

https://bitcointalksearch.org/topic/m.528001

You know this has been discussed many times before. it would be really best if you'd spent some more time studying them rather than starting a new thread and externalize the studying cost…

You seem to know the primary arguments against it, but I'll repeat the ones I think are most interesting:

(1) Orphaning rate depends on the time relative to communications & validation delay (formula given in the link).  At the limit as the block-time goes to zero the network will stop converging and typical reorganizations tend to infinitely long.  The actual delays depend on network topography and block size. And as an aside— in the past we've seen global convergence times on Bitcoin get up to over two minutes, although the software performance has been improved since then it doesn't seem that there a ton of headroom before convergence failures would be likely in practice, certainly fast convergence is harder with larger blocks.

(1a) There have been altcoins who didn't understand this and set their block times to be stupidly low and suffered pretty much instant convergence failure (e.g. liquidcoin). There are other ones that may start failing if they ever get enough transaction volume that validation actually takes a bit of time.

(2) The computational/bandwidth/storage cost of running a SPV node, or query a remote computation oracle for signing, or to present a bitcoin proof in a non-bitcoin chain is almost entirely due to the header rate. Going to 5 minutes, for example, would double these costs. Increasing costs for the most cost-sensitive usages is not very attractive.

(3) With the exception of 1 confirmation transactions, once you are slow enough that orphaning isn't a major consideration there is no real security difference that depend on the particular rate. For moderate length attacks sum computation matters and how you dice it up doesn't matter much. One confirm security— however— isn't particular secure.

(3a)  If there is actually a demand for fast low security evidence of mining effort,  you can achieve that simply by having miners publish shares like P2Pool does. You could then look at this data and estimate how much of the network hashrate is attempting to include the transaction you're interested in.  This doesn't, however, create the orphaning/convergence problems of (1) or the bandwidth/storage impact on disinterested nodes of (2).

(3b) Because mining is a stochastic lottery confirmations can take a rather long time even when the mean is small. Few things which you can describe as "needing" a 2 minute mean would actually still be happy with it taking 5 times that sometimes. Those applications simply need to use other mechanisms than global consensus as their primary mechanism.

(4) While you can debate the fine details of the parameters— perhaps 20 minutes or 5 minutes would have been wiser— because of the above none of the arguments are all that compelling.  Changing this parameter would require the consent of all of the surviving Bitcoin users, absent a really compelling argument it simply isn't going to happen.

If you'd like to explore these ideas just as an intellectual novelty,  Amiller's ideas about merging in evidence of orphaned blocks to target an orphaning rate instead of a time are probably the most interesting—  the problem then becomes things like how to prevent cliques of fast miners self-centralizing against further away groups who can't keep up, and producing proofs for SPV clients which are succinct in the face of potentially quite fast blocks.

I know it was dicussed many times before. But, I didn't find clear, convincing analysis, showing advantages of 10 min blocktime over shorter times.
From this topic: https://bitcointalksearch.org/topic/m.2666847 it seems, that in the first approximation orphans rate doesn't depend on target blocktime. Of course, after all, it depends. But again, is there a solid analysis of this dependancy?
Are there other advantages of longer blocktimes over shorter ones?
On the other hand, there are clear advantages of shorter blocktimes over longer ones. One can argue, that those advantages are more of cosmetic, marketing nature. But we shouldn't underestimate importance of marketing. And not all of the advantages are cosmetic. E.g. with shorter blocktimes one needs much less time to estimate honesty of a non pps mining pool.