Bitcoin Forum

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?

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

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

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.

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.

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?

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.

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.

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

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

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.

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

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.

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

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

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.

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:


Now let's look at the actual time between blocks: it's somewhere around 7 minutes (actually 7.98 min (http://blockexplorer.com/q/interval) 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.

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.

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.

I can't agree that bitcoin is not designed for over-the-counter payments

Please explain how you don't agree? Bitcoin was designed with a 10 minute block target time. This is not conducive to over-the-counter payments where a quick confirmation is desired, therefore it was not designed for over-the-counter payments...

Sergio (or anyone else),

Can you tell me please what the difference (security wise) is between a bitcoin transaction propagated through the network 2.5 minutes ago with zero confirmations and a "FASTCOIN" transaction propagated at the same time but now with 10 confirmations (15 second block time)? Which transaction is easily to disrupt (read "reverse"/ullify etc)? Assuming both coins had equal hashing power which transaction would require more hashing power to sabotage. Which transaction is the most secure? If someone is trying to doublespend what difference does the number of confirmations make? - Surely it is just the amount of hashing power that makes the difference...?

Does this scale for more confirmations:
> 30 minutes (3BTC conf., 120FASTCOIN conf.)?
> 60 minutes (6BTC conf., 240FASTCOIN conf.)?

Please of course consider that both transactions adhere to the network rules of that network
> Is the transaction valid
> Has it propagated through the network sucessfully
> Is double-spend attempt detected (can tell this after a few seconds usign well-connected nodes)
etc...

I dont see how they are different and can only understand increased bandwidth/orphan rate generation as negative side effects.. Also increasing percieved security whilst really not providing any additional security.

It seems to me like the only issue we have currently is education; people dont really understand why you dont need to wait for 6 confirmations for a tx to be "secure"...

Although I could well be wrong on a number of things as I am not a miner or a developer.

Once the transaction is in the network within a few seconds a double-spend can be detected by most nodes.  If the transaction has a fee (and for most that don't have a fee, e.g. non dust, valid transactions etc) once the transaction has been accepted in the network without a double-spend attempt, a confirm gets you very little in terms of security because it will confirm under all but one in a billion circumstances.  Transaction acceptance is nearly instant - less than a few seconds in most cases, faster than a credit card swipe.

For larger amounts where you have no trusted relationship with the other party and where you have no other legal recourse with the other party, some confirmations are needed.  Buying a car or real estate, you'd want some confirmations, but in the use case above for smaller over-the-counter payments don't need a quick confirmation because the transaction has been accepted in the network and will confirm.

If you go into Starbucks and buy a copy of coffee and successfully double-spend it (highly unlikely given the costs involved and items you're attempting to steal), Starbucks will call the cops or write it off.  No one is going to try and steal a small-value over the counter payment because it is impractical and not worth the effort, and even if they tried it would almost definitely be unsuccessful.  For large transactions, such as a car, the transaction will likely confirm in the next block because of the transaction priority - waiting on average 10 minutes for a confirmation in this case is not unreasonable even though the dealer would have legal recourse in the case of fraud.

In short, you may "desire" a quick confirmation, but it is not needed in terms of transaction security for lower-value over-the-counter payments that have been successfully accepted into the network.

@e4xit, the probability of successfully performing an attack when you are less than 50% of the network hash rate decays exponentially with the number of confirmations.

Yes, except as soon as I leave the store I could send those coins to another wallet (as I know the private key). A smart sales assistant would make you wait in the store while he/she transfered to coins to a new address. You would still have to wait for confirmations.

The consensus is that block sizes will be increased at some not-too-far-off point in the future.  Wouldn't the convergence times be pushed up by larger blocks?  Halving the time would still double the number of blocks and therefore, headers, so it would increase the load on SPV servers.

Not every thing is going to be point of sale or online orders where 1 hour is an okay wait.  There are going to be plenty of transactions where people or businesses wait for a confirmation or two.  I'm just saying 5 minutes would be nice.

a 5 min wait over the counter is still not good enough. just ask around for those who have experience withdrawing cash from bitcoin atm. its pretty bad atm.