Topic: Is the long block confirmation time a problem? (Read 3355 times)

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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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.

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://bitcointalksearch.org/topic/reasons-to-keep-10-min-target-blocktime-260180
I wonder if any of there thinking has changed after seeing all of the new coins that make do with very short block times.

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

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.

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

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.

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

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

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.