Is the long block confirmation time a problem?

[11inches]

I have been spending a lot of time thinking about this lately and I keep coming to the same conclusion...It's definitely an inconvenience when you compare it to something like Litecoin.

Yes, I understand that for small purchases vendors can just accept 1 confirmation or 0 confirmations but for every other transactions it can take upwards of 10 minutes...or an hour if you need 6-10 confirmations like a deposit to an exchange

like i said, probably not a big deal but is there any room to change this in the future? or are we stuck with this forever?

[zetaray]

That is why most would say bitcoin is not designed for over-the-counter payments. I think we are stuck with this block time, but we can develop off chain payment systems

[jl2012]

https://www.google.com/search?safe=off&espv=2&es_sm=93&q=confirmation+time+bitcoin&oq=confirmation+time+bitcoin&gs_l=serp.3..0i19j0i5i30i19j0i8i30i19l3.13333.15881.0.16032.7.7.0.0.0.0.74.320.7.7.0....0...1c.1.39.serp..0.7.312.CKEsFGSbTnk

[descarte]

You bet it is. No matter how other people try to whitewash bitcoin, long confirmation time is the biggest problem of mass adoption of bitcoin right now.

I just went to a bitcoin ATM operated by robocoin. The other day I sold 1000 worth of bitcoins and I got 1 confirmation in 5 minutes.
the atm just needed 1 confirmation and it took 45 mins to get 1 confirmation today for 500 worth of bitcoins.

A shop owner that I talked to was also so pissed of with bitcoin that he wanted to puke. Everytime someone orders something, waiting for the confirmation is just way too long. So if bitcoin is not "over-the-counter" ready, then it is not ready for mass adoption.

Perhaps buying a pizza or something cheap isn't a big problem...

I strongly suggest the developers to focus more on this issue.

[11inches]

It's just becoming more and more of an exaggerated nuance as I deal with various alt-coins. I transfer my LTC/DOGE back and forth from my wallets, exchanges, services, etc... and all is swell. I come back to Bitcoin and it's hard to ignore it.

[precrime3]

How would having like paper wallets with $20 of btc on it work? We could carry slips of paper around, and when we had to pay for something, here's a .05 btc bill.. Other person would scan  it to check balance and confirm, and then you would hand over paper wallet. Quicker than 6 confirms right?

[teukon]

You bet it is. No matter how other people try to whitewash bitcoin, long confirmation time is the biggest problem of mass adoption of bitcoin right now.

I just went to a bitcoin ATM operated by robocoin. The other day I sold 1000 worth of bitcoins and I got 1 confirmation in 5 minutes.
the atm just needed 1 confirmation and it took 45 mins to get 1 confirmation today for 500 worth of bitcoins.

I think the problem here is more with a Bitcoin ATM which is designed to wait for 1 confirmation.  There's still plenty of work to be done in the space of "fast payment verification" and I'm looking forward to see further market solutions (green addresses was one).

Deposit banks are one part of a solution.  People would keep some of their bitcoins in a bank and the ATM would be able to accept transactions from the bank with no confirmations.  This could be arranged to maintain anonymity.

A little more sophisticated: Payment insurance companies would allow people to pay with bitcoins quickly and directly.  Such a company will charge a subscribing merchant a monthly fee and require the merchant to reject certain transactions it deems invalid in a short time window (say 5 seconds).  It will pay out in full if any of the transactions it deems valid in that 5 second window are successfully double-spent.  Consequently, the insurance company would have a strong incentive to make sure they are very good at detecting potential double-spends, while letting through as many innocent transactions as possible.  They would be well-connected to the network and would probably spend a lot of money analysing the blockchain.

This isn't really a problem for the core devs.  Besides, ensuring that sufficient decentralisation is maintained as the network scales is a more pressing concern.

Finally, while this is a problem for Bitcoin's adoption today, it is important to note that cryptocurrencies which have the same essential model as Bitcoin but simply set a lower confirmation time are not solving the problem, they are just adjusting the balance between this problem and that of orphans.  I'm wary of this approach, simply because the orphans problem becomes more serious as the network scales.

[dreamspark]

Satoshi knew what he was doing with the confirmation times, its a great balance between speed, orphans and importantly space. Yes I know HDD memory isn't expensive but massive blockchain does cause problems. Look at the rate of growth of some of the fast confirming coins blockchains and imagine the size of them in 10 years if they grew in transaction size to the point of BTC.

[Rannasha]

Satoshi knew what he was doing with the confirmation times, its a great balance between speed, orphans and importantly space. Yes I know HDD memory isn't expensive but massive blockchain does cause problems. Look at the rate of growth of some of the fast confirming coins blockchains and imagine the size of them in 10 years if they grew in transaction size to the point of BTC.

A block takes up 215 bytes plus the size of any transactions beyond the coinbase transaction it contains. That means that Bitcoin blocks take up ~10 MB per year or about 50 MB since the inception of Bitcoin. The rest of the blockchain size is made up by the additional transactions that were made.

Had Bitcoin been made with a 1 minute block-target, the blocks themselves would've taken up about 500 MB, still rather small compared to the total size of the blockchain.

[kjj]

If only there was some way to have a third party mediate certain transactions...  This third party could manage the risks inherent in all transactions, and could smooth over the mismatch in risk preferences between fast transactions and secure transactions.

This third party could operate a computer network with terminals at each merchant's point of sale, and at each consumer's risk guarantor.  Payers could identify themselves with plastic cards bearing magnetic stripes and/or tamper resistant CPUs...

[edmundedgar]

You bet it is. No matter how other people try to whitewash bitcoin, long confirmation time is the biggest problem of mass adoption of bitcoin right now.

I just went to a bitcoin ATM operated by robocoin. The other day I sold 1000 worth of bitcoins and I got 1 confirmation in 5 minutes.
the atm just needed 1 confirmation and it took 45 mins to get 1 confirmation today for 500 worth of bitcoins.

A shop owner that I talked to was also so pissed of with bitcoin that he wanted to puke. Everytime someone orders something, waiting for the confirmation is just way too long. So if bitcoin is not "over-the-counter" ready, then it is not ready for mass adoption.

Perhaps buying a pizza or something cheap isn't a big problem...

I strongly suggest the developers to focus more on this issue.

The question here is whether there are a lot of use-cases where:
1) You really do need to wait for a confirmation.
2) 10 minutes+ average is too long.
3) 1 minute+ (or alternative) is short enough.

There are certainly plenty of use-cases that satisfy (1) and (2), but for a lot of them (3) is still not good enough. In the ATM example even if you imagine the whole thing was 10x faster that's still 4.5 minutes, which still feels a bit too long to leave someone waiting around awkwardly. If you can get below a few seconds a lot of new use-cases open up, but at that point we're probably looking at a quite a fundamentally different technology to this one.

Short-term the solutions are probably elsewhere - for example, put the ATM in a restaurant or cafe, transfer your bitcoins when you come in, have your lunch or coffee, and collect your cash when you leave...

[maaku]

Decreasing the blockchain linearly increases the load on mobile clients which sync block headers. Off-chain solutions are required to get down to the ideal time of <1sec.

[dexX7]

I think it's not a problem. These resources may be helpful to get an idea of what might be possible:

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
https://en.bitcoin.it/wiki/User:Aakselrod/Draft

[Sergio_Demian_Lerner]

I can't imagine anyone complaining because the block interval is too short, if Satoshi had chosen a 1 minute block interval.

Can you imagine a dialog like this in an hypothetical world where Satoshi had chosen a 1 minute block interval?

- Ohh, I get confirmations too fast, it gets on my nerves!
- Yes, I hate paying so fast. If Satoshi had chosen a 1 hour block interval instead of 1 minute I would think twice before buying such low quality products I bought yesterday.
- Everyone is using it to pay at the retail stores, and that's very bad for online shopping. That's against the future we dreamed!
- Could we fork the coin and make it much slower?
- Wow! We could create a whole community that seeks laziness and less productive work around a new coin! Then WE could get millions!
- Let's call it BitSlow. Out slogan should be  "the cryptocurrency with 1 hour block interval that protects you from compulsive buying disorder"

Sincerely, there is no reason, with the knowledge we have today, not to reduce the block interval with a hard fork instead of increasing the block size.

It's possible to reduce the interval down to 5 seconds without any practical drawback, as it is explained in my blog post:

http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/

Best regards, Sergio.

[BunsenBurner]

like i said, probably not a big deal but is there any room to change this in the future? or are we stuck with this forever?

It could be changed, but it will cause a hard fork.

[Cubic Earth]

Sincerely, there is no reason, with the knowledge we have today, not to reduce the block interval with a hard fork instead of increasing the block size.

I've been advocating the same thing for a while.  While I understand the desire to keep bitcoin operating in a very conservative manner, there are lots of examples of stable coins with shorter block times.  Dropping the block target to 5 minutes would carry no risk to the network.

While a 5 minute block time wouldn't solve point of sale type issues, it would save anyone who is waiting for confirmations 5 - 15 minutes.  That would be a real savings of time, and I think the community would be very excited by it.

But plenty of experts disagreed with my thinking in this thread https://bitcointalk.org/index.php?topic=260180.0
I wonder if any of there thinking has changed after seeing all of the new coins that make do with very short block times.

[instagibbs]

Yes, let's hurry to change a parameter that won't make point of sale any nicer versus credit cards without understanding any of the underlying effects of doing so.  

Simply pointing to an alt that tries short blocks means nothing until determined schemers, hackers, greedy miners, etc start attacking the network. That doesn't even begin to think about how it will effect centralization. Network speed and connectedness network may be even more important than it is now.

This whole discussion ignores that 95%+ of use cases of Bitcoin basically make double-spending a PITA or impossible.(unless you have an in with a large mining pool, which would still be a problem with shorter times)

I'm not against the idea philosophically, I just think it's not really baffling why Core Devs and others are tripping over themselves to do it.

[dexX7]

Dropping the block target to 5 minutes would carry no risk to the network.

Please don't get me wrong, I also read your posts in the other thread, but I think using some altcoins as reference to back up this statement is not enough. Only because there were no visible consequences in a smaller environment over a limited amount of time doesn't guarantee it would carry "no risk" to the network. From the other thread:

... 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 ...

Now let's look at the actual time between blocks: it's somewhere around 7 minutes (actually 7.98 min at the moment) due to the increasing hashrate and with even lower times during peaks. With a halved block time the time between blocks would therefore reduced to times of somewhere around 3.5 minutes. Indeed not much of headroom. Risks aside, it would also increase the overhead whereby this primarily affect thin clients.

At least in my opinion - the benefits of a slightly reduced block time are marginal. 5, 8 or 10 minutes is somewhat similar and not much of a difference. 5 minutes are still way too long for use-cases in which any delay longer than a few seconds naturally becomes a burden, e.g. paying a drink at the bar. Sure, it would be nice to wait a little less, but it doesn't provide a real solution for the underlying problem.

I'm in favor of finding alternatives instead of using quick fixes.

[maaku]

And let me reiterate -- dropping the block interval has real measurable negative effects on bandwidth usage of mobile / lite clients. So yes, lets cripple the vast majority of users so you don't have to wait a few more minutes.

[andrewbb]

What I call a "Promise Assurance" company would solve the problem.

A standard protocol to convey the transactions amongst companies.

An ATM transaction example:

Initiating promise:  1 BTC
Notice - accept:    $600 USD
Notice - assured:   VISA, MC, Discover, Amex (or other bank)
Promise:               $600 USD
Deliver:                $600 USD
Deliver:                1 BTC
End transaction.


Note that the "Notice - assure" message is a "Promise Assurance" from a 3rd party for instant delivery.   That would be pre-arranged and one would be in a contractual relationship with that entity.  That way the vendor or ATM owner is not taking risk as both the ATM owner and you both trust the "assurance" entity.