Is the long block confirmation time a problem?

[Monkeyseemonkeydo]

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

[1715467078]

1715467078

[1715467078]

1715467078

[dreamspark]

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

[e4xit]

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.

[cr1776]

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

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.

[maaku]

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

[anonuser777]

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?

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.

[Cubic Earth]

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.

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.

[descarte]

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.