Bitcoin Forum

With Litecoin at 2.5 minutes and Dogecoin at 1 minute , they seem faster to confirm as compared to Bitcoin's 10 minutes.
This is one of the few features for which Altcoin enthusiasts claim superiority over Bitcoin.

Are there any side-effects to having a lower average block time ?
What if Bitcoin was suddenly hard-forked to have a 5 minute block time , with instantaneously halved reward ?
Would there be any negative effects ?

Does this mean that altcoins with a lower block time are inherently superior to Bitcoin ?
Then at what point does it become a bad idea to reduce block time further ? 30 seconds ? 15 seconds ? 5 seconds ?

My understanding is that shorter block time increases orphans but I'm not sure that actually is true.

Yes, bitcoins block time is too long - but it also was the first of the first, not all parameters are going to be perfect on the first of the first.

To be honest I'm impressed at just how good it really is. The long block time is not a fatal flaw.

I was thinking that the developers would have put thought into it , and aimed it for the best possible block length for global adoption.

So , my question was why didn't they go lower ?

To reduce orphans makes sense , but I'm not sure how much of an effect this has.

It's my understanding that in order to successfully double spend you need to be able to mine your own block. And shorter block times makes that alot easier to do. So 10 min block time makes it very hard to double spend in bitcoin.

It's orphans. Orphans happen when two miners solve a block at approximately the same time (one one can survive). Assume any blocks that are solved within 5 seconds of each other could possibly cause an orphan. If blocks are normally one minute, blocks within 5 seconds is a 1/12 event (8% orphans). If blocks are 10 minutes, this is a 1/120 event (<1% orphans). These are close to the numbers seen on actual coins.

Its not only orphans, but a compromise of several factors:

For a short blocktime speaks that it shortens the time to the 1st confirmation as well as any following confirmation. You also have less variance in the payouts thus less need for big pools. 1 block every 10 minutes (on average) means one mining party gets a reward every 10 minutes. If you can mine 10 blocks in 10 minutes chances are very high that more parties get a reward.

For a long blocktime speaks that it requires less bandwith because the nodes need to propagate new blocks less often.  Also the orphans which are caused by forks and result in wasted hashing power. So a longer blocktime make forks less likely and thus increase security.

Its a tricky balance though as we see with ghash.io. Miners tend to flock to big pools in order to have a steady income, which increases the possibilty of an 1
>50% attack.

Yeh, a shorter time isn't safer and is easier to be exploited, though many alt coiners don't realise this. The time it takes to process transactions or get confirmations really isnt a problem and is there to safeguard users and strengthen the system.

Apart from orphans, it's propagation time, Satoshi chose 10 minutes to allow the whole network to receive the new block in sufficient time, whereas shorter block time limits this somewhat, so some nodes stay behind if their connection is slow.

It increases the orphan rate, because the ratio of network propagation time and median time of finding a block gets worse.
Also, it effectively does make the coin unsafer, since it doesn't matter how many blocks get mined, it just boils down to the amount of computing power you need to mine those blocks in order to create a longer chain. It remains the same.

While increased orphans is a problem, if a transaction is in one block it is likely to be in the competing block too.

What short block times need to do is require X confirms before the input is spendable.

This is just one kind of double-spending attack...called the Finney attack after Hal Finney. It's the hardest to defend against but also the most costly to perpetrate. Most double-spends would be simply sending one transaction to the target and another to the rest of the network and hope that the target has not protection against that.

Fast block times increase orphans and increase the amount of hashing that is wasted since miners will be mining on the wrong block more of the time. 10 minutes was a good guess. At least it wasn't 30 minutes or an hour. Litecoin's 2.5 minutes appears to be working out ok but time will tell as transaction volumes go up which is better.

Vendors can already decide how many confirmations they will require (if any), so this isn't a protocol problem.  Beyond that, the amount of computing power supporting the network and the amount of time necessary (on average) to generate confirmations are factors in how secure a transaction is.  So, based solely on block time, a transaction on a coin with a 1 minute average confirm takes 10 confirms to be as secure as a transaction on bitcoin with a single confirm.  However, when you factor in computing power, that gets even more complicated.  For instance, 1MHash/s of Scrypt is not equal to 1MHash/s on another algorithm, so you can't really compare Bitcoin and Litecoin security in terms of Hash/s to determine how many additional confirms would be necessary in addition to the quadrupling of the number of bitcoin confirms to match litecoin's 2.5 minute block average.  In regards to how to compare the security of various coins with different algorithms, I don't know what measure would be best (flops? watts? IOPs? etc?).

Yes, the average block time of Bitcoin is merely a tradeoff set by Satoshi. If we want to see how other coins perform with other block times, and also other parameters different from Bitcoin, we can just look at the altcoins. I'm not saying that other block times are better or worse. I just think that they don't matter as much as people think they do.

I think where shorter matters is with mobile clients.

No mobile platform is really secure. You don't want to keep a lot in a mobile wallet, it is better to load your mobile wallet when you are going out with intent to spend but otherwise (just like a leather wallet) don't keep a lot in it. Unless you are only going to spend in one place, or you transfer to it using lots of outputs, confirmation time impacts when your change address from Merchant A is available to buy something from Merchant B.

It also matters for things like phonesex, but that's a different topic.

Ok So do we have devs testing out shorter block times? to see the effects, for example I heard someone here say litecoins 2.5min block time is wrking well but only time will tell. How much time will tell?

 Are we saying that 10min is the sweet spot? WHo is testing anything less?

If we are definite that 10 confirms from a 1min block time = 1 confirm from a 10 min block time in terms of security ... then that means there Is no solution other than to reduce security.

Also when we say less secure what does this mean, Eg; If I spent a coin on a 1min block time and then we got 2 confirmations how is this less secure than 2 confirms on a 10 min block time?

And is the attack on this HARDER to perform on a small block time than the double spend attack which one can do with a 0 confirm acceptance in a 10 min block time? As far as I know a 0 confirm double spend attack is quite easy right? Simply use a mobile and laptop with the same wallet and send the same coin twice?

There are probably coins with shorter block times than this but Cinnicoin's 15 seconds is too short. It produces too many blocks which seems like it slows down the blockchain download experience (it really is an experience).

There would be more data produced in a batch of 40 * 15 second blocks than a 1 * 10 minute block with the same amount of transactions in it... right? (I don't know this for sure)

At the other end of the spectrum you have (had) Unattanium with 10 hour blocktimes (or something around there), which was an interesting experiment but the dev had to recalibrate the blocktime to make it not such a pain in the ass to move around (mainly to and fro the exchanges).

I imagine in order to maintain the "Unattainum" meaning he had to reduce the rewards significantly, which may be a disincentive to mine, if they are not already mining "Unobtainum" first...  :D

Lots and lots of coins are testing all kinds of block times.

Unfortunately people tend to have no real clue why Satoshi picked 10 minutes and just go with "we want faster transactions" (occasionally "we want to make it easier to mine blocks") and then make it much shorter without doing anything else to address the underlying justification for 10 minutes.

The numbers in my previous post are more or less right (obviously it depends on the specifics of the p2p network and a few other factors). So if you want a low orphan rate (1% or less) in a distributed p2p network you are stuck with something like 10 minutes.

There's nothing to test, it is all statistically defined.  Quite frankly, while it isn't necessarily obvious why 10 minutes was chosen without statistics, some effects of changes to the target block length are obvious without statistics:
1)  The more frequently blocks are created, the less efficient the blocks wil be in terms of storage (each block takes a minimum amount of disk space, the more transactions are in it, the more space it will take, but the less of the total space used is wasted just to record blocks vs actually storing transactions).
2)  The easier blocks are to create (vs a difficulty-based time-target), the more frequently multiple nodes will be submitting competing blocks
3)  The easier it is to create blocks, the easier it is to create a chain of blocks secretly and release it in any kind of attack (double-spend, "51%", etc)

Another way to word why we are sure of this:  Security of a transaction is not directly based on the number of blocks, it is based on how much hash power is behind confirmation and how long it has been behind it.  With a 10 minute block average, you need enough computing power and luck to override 10 minutes worth of work from the entire network.  With a one minute block average and two blocks, you only need enough hash power and luck to override 2 minutes worth of work from the entire network.  To remove the imagined first block convenience, you can also look at it this way: 11 blocks is going to come around on the two-minute network before 2 blocks comes around on the 10-minute network, so assuming equal computing power, you sometimes have slightly more security slightly sooner on a network with shorter blocks, but that doesn't make it valuable enough to ignore points (1) and (2) above.

Regarding the "imagined first block convenience": the protocol states that all nodes will broadcast a valid transaction when they see it (a valid transaction does not use inputs from another transaction that is already showing on the network, preventing double-spends from using the entire network [double-spends have to be made via secret mining or broadcast of two transactions at the same time <within a fraction of a second> so only part of the network is working on each of them, neither of which are guaranteed to be successful]).  Statistically (as in, before you take into account that payment providers are centralized), this means that an unconfirmed transaction is generally on most of the network when a merchant sees it.  Given this, and considering the expense one would incur to perform a double-spend and the laws one would be breaking as well, it is simply not worth it to attempt to double-spend for any transaction where you aren't scamming someone out of a very significant amount of money, so merchants generally don't need to wait for confirmations as long as the transaction can be reasonably expected to complete (for instance, it has a fee).  For transactions where a double-spend would be worthwhile (probably buying something at least as or perhaps more expensive than a car), waiting for multiple confirmations is not really a big deal, and quicker confirmations would probably mean waiting for more confirmations anyway.

The only potentially real convenience to a quicker block confirmation I have seen suggested by anyone was by AliceWonder, and that is if you spend from one input, and need to spend from the change output of that transaction down the street, you might not be able to send the new transaction until there is a confirmation, but I don't think that is 100% true.  I believe it is possible to create and send transactions from unconfirmed outputs, they just can't confirm until their parent transactions do, too.  However, even if that weren't possible, if bitcoin were common enough to be spending it in two places in close proximity to one another in a less than 10 minute average interval, and you had enough bitcoin to be spending at each of these places, there is no reason you couldn't have multiple inputs to spend from separately with just a little bit of planning.  To that end, there are a lot of shops where you can't get change for a $100 bill, so it's not like planning ahead to split up the inputs is any different than planning ahead to have five $20 bills instead of one $100 bill.  ETA: and you can make the change yourself instead of having to go to a bank or out of your way to a big store that can make change for the $100 bill.

For regular people and real world daily use shorter block times are superior, no question about it.

If you're not comfortable making a regular size transaction on one confirmation then there are bigger problems at play.

Yes, some hash will be wasted. So the question is, what is a more important attribute for a currency? Ease of use or most efficient use of hash?

From what I have heard, will increase orphans and also increase the possibility of forks

Orphans, Forks.. Both very serious problems in the incentive structure of a coin.

Also the shorter the blocktime, the less secure is a confirmation. Because less luck is needed to "overtake" the network speed with <50 %  hashpower.

Doublespending!

ok guys.

no matter if its 10minutes, 2 minutes or 1 minute. the argument will continue on and on and on forever, where people will say:
"but at starbucks if a customer wants a coffee, do you realise how long a minute is between the time of the customer paying, and then being to to not move, not leave. whilst the cashier sits there waiting the whole minute for the coin to confirm. in that minute you will probably have a 2 more people coin the queue. then on the second customer 2 more people join the queue, meaning now 3 waiting. and so on"

so no matter how long the confirm time is .. its too long.
so forget confirmed transactions. PLEASE!

please get it out of your mind that fast food places will ever wait for confirmations. instead this is the only 2 solutions
1. accept unconfirmed, because the value is low.
2. just like paypal (pre deposit funds to get confirmed) then simply move funds OFFCHAIN to the recipient, via a third party wallet service that has liability insurance to cover each customer for a daily spend amount of under $100 of bitcoin.

as for products over $100 then you can argue about confirmation times, which customers and merchants would be more acceptable to wait around for.

There will be easy services for that. like "green"-addresses, where the merchant can be sure that he will get the BTC.

Easy 0-conf acceptance.

10 minute confirmations is a good amount of time for confirmations. On average there is only a 1/600 chance that a particular block mined will be orphaned. If you get the chances of an orphan to be much higher then that, then it becomes a better possibility that the only block that a miner finds in a day, or a two week period is orphaned due to a small percentage of the overall network hashrate. If the confirmation time is too much longer then it would take too long for transactions to confirm, making it less convenient for consumer use.  

I don't know about you but when I go to Starbucks I see almost every single customer using a Starbucks prepaid card. The only thing you need BTC for is to reload the card, which can take as long as necessary.

yep you get it. what you just said is my solution number 2