Will a shorter block time be helpful or harmful to Bitcoin and its future?

[jaywaka2713]

Almost everyone has seen the alternate currencies section of this forum. There has been just about one hundred coins developed, all with a variable range of block times. We have seen one benefit from this mass testing, and that benefit is faster block confirmation times.

I, a two year long Bitcoin user, have experienced the issues with the current 10 minute block time. There has been endless discussion about making zero-confirmation transactions safe, but what if a lighter solution is better? Why not reduce the block time? Now, I understand that a block time of 30 seconds does nothing but damage, and will not propose that, but what about a block time of 2 minutes? That will speed up transactions by 500%, and will make the hour-long transaction something of the past.

That 2 minute block time is long enough to prevent any orphans at all, and the network has been very well developed up to this point. However, changing the block time changes other things as well. One such example would be block reward. At the time of writing, the block reward is set to 25 BTC. So if the block time were to be changed to 2 minutes, the block reward would need to be changed to 5 BTC.

Yes, there are drawbacks to this change. One such drawback would have a direct effect on those who solo mine. Mining is really a game of chance. Cracking a block would only give you one fifth of the reward. There are also pros as well. This would allow pools to have higher odds in cracking blocks as well, as blocks are created 5 times faster. Block reward would continue to halve along with the current plan.

My main point is that transactions are simply too long. The one advantage the banking system has over us is instant transactions. Reducing the time required for about 6 confirmations from half an hour/hour to around 10 minutes would be very helpful. Also makes 1 confirmation transactions very fast as well. Thoughts?

[BitAddict]

I guess shorter time should be better. But I want to listen the opinion of the old members.

[jaywaka2713]

I guess shorter time should be better. But I want to listen the opinion of the old members.

I too am very interested in their opinions. Block time is one of Bitcoins big issues for massive adoption, but is one of the easier issues to fix as well. The repercussions of such a change have to be discussed though.

EDIT: Fixed Poll. Yes/No were invalid answers to the question LOL.

[Kluge]

Faster block conf times leads to a higher rate of orphaned blocks, increases the likelihood of dishonest folks from succeeding in double-spends in certain circumstances, and creates a larger blockchain.

A confirmation is not a guarantee of authenticity. Decreasing conf time proportionally decreases the "value" of the confirmation. Decreasing confirmation times would be accounted for in services requiring confirmations, where required confirmation times would be increased to completely negate the decreased conf times. (for example, Gox requires 6 confs -- reducing conf time to 5m would result in Gox requiring 12 confs)

... That said... to compromise the Bitcoin network back when the six-conf suggestion was suggested, it was dramatically less expensive to have double-spends confirm. Three confirmations is now more than adequate for all transactions under hundreds of thousands in USD. Going beyond is really just (inadequately) protecting yourself against a fork. Maybe it is time to discuss lowering the target conf time?

ETA: Devs may also be trying to encourage Bitcoin transactions to occur internally on central servers to keep "casual" transactions off the blockchain... OTOH, they seem to be in general consensus that the block size should be increased in the near future. I'm sure one'll come in soon and tell us what's up.

[jaywaka2713]

Faster block conf times leads to a higher rate of orphaned blocks, increases the likelihood of dishonest folks from succeeding in double-spends in certain circumstances, and creates a larger blockchain.

A confirmation is not a guarantee of authenticity. Decreasing conf time proportionally decreases the "value" of the confirmation. Decreasing confirmation times would be accounted for in services requiring confirmations, where required confirmation times would be increased to completely negate the decreased conf times. (for example, Gox requires 6 confs -- reducing conf time to 5m would result in Gox requiring 12 confs)

... That said... to compromise the Bitcoin network back when the six-conf suggestion was suggested, it was dramatically less expensive to have double-spends confirm. Three confirmations is now more than adequate for all transactions under hundreds of thousands in USD. Going beyond is really just (inadequately) protecting yourself against a fork. Maybe it is time to discuss lowering the target conf time?

ETA: Devs may also be trying to encourage Bitcoin transactions to occur internally on central servers to keep "casual" transactions off the blockchain... OTOH, they seem to be in general consensus that the block size should be increased in the near future. I'm sure one'll come in soon and tell us what's up.

Actually, after the extensive testing of various altcoins, 2 minutes for a block time will not create many orphans at all, if any. After reading your post, it is obvious to myself that I do not fully understand what a confirmation is. Can you send me a link for me to read concerning confirmations?

You also said something about dropping the confirmation time. I was not aware such a variable existed. Would that decrease the integrity of the confirmations?

[Kluge]

Faster block conf times leads to a higher rate of orphaned blocks, increases the likelihood of dishonest folks from succeeding in double-spends in certain circumstances, and creates a larger blockchain.

A confirmation is not a guarantee of authenticity. Decreasing conf time proportionally decreases the "value" of the confirmation. Decreasing confirmation times would be accounted for in services requiring confirmations, where required confirmation times would be increased to completely negate the decreased conf times. (for example, Gox requires 6 confs -- reducing conf time to 5m would result in Gox requiring 12 confs)

... That said... to compromise the Bitcoin network back when the six-conf suggestion was suggested, it was dramatically less expensive to have double-spends confirm. Three confirmations is now more than adequate for all transactions under hundreds of thousands in USD. Going beyond is really just (inadequately) protecting yourself against a fork. Maybe it is time to discuss lowering the target conf time?

ETA: Devs may also be trying to encourage Bitcoin transactions to occur internally on central servers to keep "casual" transactions off the blockchain... OTOH, they seem to be in general consensus that the block size should be increased in the near future. I'm sure one'll come in soon and tell us what's up.

Actually, after the extensive testing of various altcoins, 2 minutes for a block time will not create many orphans at all, if any. After reading your post, it is obvious to myself that I do not fully understand what a confirmation is. Can you send me a link for me to read concerning confirmations?

You also said something about dropping the confirmation time. I was not aware such a variable existed. Would that decrease the integrity of the confirmations?

Sorry. I write like a shithead, sometimes.  I'll try to clarify some points I wrote particularly poorly.

When I was talking about expense to confirm double-spends, I was referring to the cost to compromise the Bitcoin network by making up a "dangerous" percentage of the total network hash rate. Network hashrate is dramatically higher now than when 6-conf suggestion was made (that is, when it was decided that 6 confirmations would be implied as "safe" by the Bitcoin client's graphics). It would likely cost millions, now, to get 3 confirmations on a double-spend, whereas it may've taken just a few thousand USD in hardware or hashpower leases far in the past. In this sense, the network is dramatically more secure, now, as it would be extremely expensive to successfully pass off a double-spend as legitimate through multiple block-solvings.

By conf time, I was just referring to the target confirmation time of a block (currently 10m). If you reduce it (say, to 5m), you are decreasing the amount of hash-power required to solve a block (exactly by half compared to what's required with a 10m target conf time). By doing so, it would be twice as easy to pull off a one-conf attack, which many would consider legitimate for smaller transactions. (but, again, this is still now prohibitively expensive even if it's twice as easy to pull off than now... one-conf probably won't be accepted as "legitimate" by most merchants selling something of significant value, so it's kind of a moot point).

The orphan argument I only picked up from others -- I haven't seen stats on it, so I'd take your word on it since I don't have any counter-examples.

ETA: Btw, don't consider me some type of authority on this stuff. I've always shied away from the technical underpinnings of BTC -- ADD, maybe. Bigger block sizes (more transactions allowed per block) might be considered a favorable option of ensuring speedy transaction processing because it doesn't introduce risks at all. Increasing block size 2x would have the same (eventual) effect as having 2x as many blocks, but wouldn't introduce the arguable risk of making merchants more vulnerable to one-conf double-spends (keeping in mind that one-conf double spends are 2x as computationally easy, and thus effectively 2x as cheap with half the conf time).

[jaywaka2713]

Sorry. I write like a shithead, sometimes.  I'll try to clarify some points I wrote particularly poorly.

When I was talking about expense to confirm double-spends, I was referring to the cost to compromise the Bitcoin network by making up a "dangerous" percentage of the total network hash rate. Network hashrate is dramatically higher now than when 6-conf suggestion was made (that is, when it was decided that 6 confirmations would be implied as "safe" by the Bitcoin client's graphics). It would likely cost millions, now, to get 3 confirmations on a double-spend, whereas it may've taken just a few thousand USD in hardware or hashpower leases far in the past. In this sense, the network is dramatically more secure, now, as it would be extremely expensive to successfully pass off a double-spend as legitimate through multiple block-solvings.

By conf time, I was just referring to the target confirmation time of a block (currently 10m). If you reduce it (say, to 5m), you are decreasing the amount of hash-power required to solve a block (exactly by half compared to what's required with a 10m target conf time). By doing so, it would be twice as easy to pull off a one-conf attack, which many would consider legitimate for smaller transactions. (but, again, this is still now prohibitively expensive even if it's twice as easy to pull off than now... one-conf probably won't be accepted as "legitimate" by most merchants selling something of significant value, so it's kind of a moot point).

The orphan argument I only picked up from others -- I haven't seen stats on it, so I'd take your word on it since I don't have any counter-examples.

OK so if I understand you right, if we drop block time by half to 5 minutes, and doubled difficulty, would that keep the hashrate necessary stable? I'm not even sure that is correct, as I didn't think block time effected hashrate requirement to crack a block. Block time is just a variable correct? Or does block time tie directly into difficulty?

[kodo]

No it will only increase Bitcoins value and be beneficial.

[Kluge]

Sorry. I write like a shithead, sometimes.  I'll try to clarify some points I wrote particularly poorly.

When I was talking about expense to confirm double-spends, I was referring to the cost to compromise the Bitcoin network by making up a "dangerous" percentage of the total network hash rate. Network hashrate is dramatically higher now than when 6-conf suggestion was made (that is, when it was decided that 6 confirmations would be implied as "safe" by the Bitcoin client's graphics). It would likely cost millions, now, to get 3 confirmations on a double-spend, whereas it may've taken just a few thousand USD in hardware or hashpower leases far in the past. In this sense, the network is dramatically more secure, now, as it would be extremely expensive to successfully pass off a double-spend as legitimate through multiple block-solvings.

By conf time, I was just referring to the target confirmation time of a block (currently 10m). If you reduce it (say, to 5m), you are decreasing the amount of hash-power required to solve a block (exactly by half compared to what's required with a 10m target conf time). By doing so, it would be twice as easy to pull off a one-conf attack, which many would consider legitimate for smaller transactions. (but, again, this is still now prohibitively expensive even if it's twice as easy to pull off than now... one-conf probably won't be accepted as "legitimate" by most merchants selling something of significant value, so it's kind of a moot point).

The orphan argument I only picked up from others -- I haven't seen stats on it, so I'd take your word on it since I don't have any counter-examples.

OK so if I understand you right, if we drop block time by half to 5 minutes, and doubled difficulty, would that keep the hashrate necessary stable? I'm not even sure that is correct, as I didn't think block time effected hashrate requirement to crack a block. Block time is just a variable correct? Or does block time tie directly into difficulty?

Conf time is indirectly determined by difficulty, with difficulty roughly determining how many hashes are required to solve a block (thus, roughly how much time is required to solve a block).

Difficulty is determined by the target confirmation time (10 minutes) and the time it's taken to solve the past 2016 blocks. With 2016 blocks each with a target confirmation time of 10m, Difficulty should adjust about every two weeks, and is meant to adjust so it always takes roughly 10 minutes to solve a block. Because we're in a period of rapid network hashrate growth with the release of ASICs, it should actually take significantly less than 10 minutes to solve a block the closer we get to the next time difficulty corrects, but also means difficulty will correct sooner than the target of two weeks. (I'm sure someone has stats, but for the past month, it's probably been something like 10-12 days for each set of 2016 blocks instead of the target 14 days)

A target confirmation time of 5m instead of 10m would require halving the difficulty.

Trivia: Cryptocoins are subject to a kind of "spiral of death" if hashrate plummets. If, say, 75% of hash power dropped from the network a day after the difficulty is adjusted, it would take (13*3), or 39 days for difficulty to adjust to that sudden drop. Confirmations would take an excessively long time to confirm, possibly eroding faith in Bitcoin and causing a kind of "hash run," where even more hash power drops off until it's nearly impossible to confirm transactions anymore, leading to abandonment (or maybe some kind of fork).

Trivia2: Changing the target confirmation time is a protocol change and relatively difficult to have accepted.

Trivia3: I'm tired as dog-shit, and someone else should be much more able to assist you than I (and hopefully correct any misinfo I gave). Good night!

[kodo]

Harmful in the future

[jubalix]

don't you need more confirmations to get the same security with shorter block times, also, I'm not sure how this would go for mass uptake

eg, when I shop, it takes the visa card about 1-3 seconds to confirm (its a pre-auth I think), and I am not sure a 1 sec is really possible with current tech, eg you would need 0.1 sec confirm to get 10 confirms and you still do have very poor security,

I may be wrong, but it a network propagation issue, that I think there is a solution by some sort....

[Liquid]

I think it should be left alone 10Mins was what the creator had intended lets not start manipulating the code thats what alt coins are for, let them have this advantage at least e.g Litecoin with 2.5mins 

[MGUK]

I've been thinking about this lately - the implications of block production time on security. It's discussed a bit in the following paper:

Rosenfeld, M. (2012). Analysis of hashrate-based double-spending, 1–14. Retrieved from https://bitcoil.co.il/Doublespend.pdf


Regarding orphans - someone mentioned that the time it takes a message to get from one end of the network to the other is 10 - 20seconds (don't know where that number comes from) but the indicator of how many orphans there are going to be is some function of the time it takes for a new block to propagate and the proportion that is of the block production rate.

e.g. 30 second block time, 30 second propagation time results in huge orphan rate.
10 minute block time, 2 second propogation time results in tiny orphan rate.

The issue of orphan transactions as well is slightly negated by quicker block production time.

e.g. it doesn't matter as much if your transaction gets orphaned once in a 30 second block rate, because it's only delayed by 30 seconds, but in a 10 minute block rate, that's 10 minute delay at least.

[jaywaka2713]

I think it should be left alone 10Mins was what the creator had intended lets not start manipulating the code thats what alt coins are for, let them have this advantage at least e.g Litecoin with 2.5mins 

He also made Bitcoin in such a way where it could be modified if need be.

Kluge, your post made sense. So we can't double difficulty because that would double block time. So by halving difficulty that's what would effect the block time? Correct me if what I'm saying is wrong. If so, that shouldn't be the way to do this. I don't understand how the 5 minute block time affects the security of confirmations though.

With confirmation time, if we were to drop that value instead, would that leave us with a faster operating coin, or would it degrade confirmation quality?

[jdbtracker]

Don't consider everything that Satoshi did as Law. I've been with the community for only a few months, but have dedicated 24/7 of my time to learn about it.

the system was built for experimentation, it is intentionally flawed to magnify certain weaknesses.

for example:

1 mb block limit was implemented = fee fluctuations can be seen when we saturate the block limit
                 
21,000,000 . 000, 000, 00 coins.  = exagerations in market fluctuations, movements caused by scarcity are more easily viewable and transferring economic data from currencies with large circulation values or extreme exchange values is cut off, at the front or back during the exchange process.

The code is extremely ambiguos, the core client was built in a very confusing manner, why?

It has a ton of features that are currently dormant and deactivated in the client, extreme flexibility would be a consideration for an experimental platform.


That 10 minute limit creates a global block saturation, everyone has the block before the next one is out even if they are running a modem connection, it even gives those 56k connections time to propagate the 1mb block, it protects against attacks from nodes with gigabit internet connections that are propagating their own preferred blocks and gives time for slower computers to confirm the hash from that block but to an exagerated level, attacks on the network are easily visible because of this architecture, it gives someone time to safely observe the attack, it is extremely exagerated 10 minutes is definitely a long time.

[GoldenWings91]

I would love to see confirmation time to go down and I think the network is mature enough to handle a five minute confirmation time, even 56kbp dial-up users would still be able to run a full node.

[Insu Dra]

eg, when I shop, it takes the visa card about 1-3 seconds to confirm (its a pre-auth I think)

This is wrong, the 1-3 sec confirm from visa is the same as zero confirm in bitcoin in 99% of the cases. The amount of fraud due to this lack of conformation with visa and master card is just hidden and swept under the carpet, payed for with high transaction costs and interest by honest users. Your bank does not get true conformation until the money hits your real account (day's, if not weeks) and even then there are the charge backs ...

People need to stop thinking visa, master card are insta, there not ...

eu deposit cards on the other hand, "maestro" in particular does have centralized conformation system in matter of seconds. (but again also charge backs on top of that)

[AliceWonder]

eg, when I shop, it takes the visa card about 1-3 seconds to confirm (its a pre-auth I think)

This is wrong, the 1-3 sec confirm from visa is the same as zero confirm in bitcoin in 99% of the cases. The amount of fraud due to this lack of conformation with visa and master card is just hidden and swept under the carpet, payed for with high transaction costs and interest by honest users. Your bank does not get true conformation until the money hits your real account (day's, if not weeks) and even then there are the charge backs ...

And Visa/MC are plagued with problems where an auth is not always removed after the charge does hit resulting in ability for the their customer to spend money, sometimes requiring several phone calls to clear it up.

[halfawake]

eg, when I shop, it takes the visa card about 1-3 seconds to confirm (its a pre-auth I think)

This is wrong, the 1-3 sec confirm from visa is the same as zero confirm in bitcoin in 99% of the cases. The amount of fraud due to this lack of conformation with visa and master card is just hidden and swept under the carpet, payed for with high transaction costs and interest by honest users. Your bank does not get true conformation until the money hits your real account (day's, if not weeks) and even then there are the charge backs ...

People need to stop thinking visa, master card are insta, there not ...

eu deposit cards on the other hand, "maestro" in particular does have centralized conformation system in matter of seconds. (but again also charge backs on top of that)

This is true.  The 1 - 3 second time for credit cards is pretty much an authorization, not a confirmation.  I bought a domain name a couple months ago and had to do the actual purchase twice because the domain registrar I bought it from is German so my credit card company thought it was a fraudulent transaction even though the card got confirmed.  So the 1 - 3 second authorization isn't the same as a confirmation.

[Eri]

The fact people dont understand parts of bitcoin is common and people always see issues with it when they dont understand it.

Thankfully for a high degree of ability to work on bitcoin you need a high degree of understanding and trust by users that understand as well, otherwise you wont have anyone backing you.

Thankfully you cant just vote to have things magically changed. we have knowledgeable developers working on the client and giving us updates that knowledgeable members can verify for the rest of the users as to whether its a smart move or to scream like mad men if its some dastardly deed to undercut bitcoin.

If you want variation from the trusted and understood basics of what makes bitcoin, then by all means please make another altcoin.

Im not against change. But the way i see it, bitcoin has a path laid out for it. so far we havnt had major problems and were still implementing its basic functions and building up infrastructure. confirmation times are a non issue, if your moving 100K USD then you can afford to wait an hour since wire transfers can take days and cost allot more. if your buying a cup of coffee then a retailer can safely ignore confirmations. the weighted risk for profit against the risk for scam is excessively low to non existent and not financially viable.

The only things polls like these show, is the number of people that understand and the number that dont.