Faster bitcoin transaction times

[Dabs]

My inputs: (pun intended, as that's the name of wallet service that died in glorious flames.)

1. Off chain transactions. All modern gambling / gaming sites do this. Some online wallets did this. Some payment processors do this. You deposit once. You play hundreds of times, sometimes several times per second, depending on what game you're into (dice, poker, slots, blackjack, card games, etc), then you can either sit on the balance or cash out later. The problem here is trust.
2. On chain transactions are typically broadcasted and accepted by 90% of the entire bitcoin network within 10 seconds. I believe the term is called "transaction confidence" or something like that. Good transactions usually mean you pay the bitcoin transaction fee, and there are no detected double spend attempts within those 10 seconds.

On a personal level, if I ask someone to pay me some bitcoin, I give them the address and wait for their transaction to appear on my client. Then I go on blockchain and look at it. I usually accept it as good even without a confirmation as long as I can see that the minimum fee was included.

For most everything else, 1 confirmation is really more than enough.

Bitcoin is best seen as a really really fast check, one that you can clearly see is "good" meaning it is "funded" and will not bounce, and one that you know will probably "clear" in an hour.

If your business accepts checks or credit cards as payment, you can probably accept bitcoin and know with a high degree of certainty that you will get paid.

[Coinhunter32]

It can be faster but current times are good too. If you are paying extra fee for faster confirmations, then it takes not less than 3 minutes for multiple confirmations.

[amaclin]

It can be faster but current times are good too. If you are paying extra fee for faster confirmations, then it takes not less than 3 minutes for multiple confirmations.

Wrong

[instagibbs]

That's a serious limitation. The customer can only send microtransactions to ONE recipient. So, as I understand it, if you prepay say 0.1 bitcoins to do microtransactions with one company, you will have to make another prepayment in order to be able to do microtransactions with another company, and a third prepayment for a third company/service and so on. That actually sucks.

You're essentially paying for space on the blockchain. You have to pay once for each recipient. It's not off-chain.

[Anders]

That's a serious limitation. The customer can only send microtransactions to ONE recipient. So, as I understand it, if you prepay say 0.1 bitcoins to do microtransactions with one company, you will have to make another prepayment in order to be able to do microtransactions with another company, and a third prepayment for a third company/service and so on. That actually sucks.

You're essentially paying for space on the blockchain. You have to pay once for each recipient. It's not off-chain.

Yes the fast transactions would have to be synched with the bitcoin blockchain. With the current proposed solution, as I understand it, a customer would need to prepay one payment channel for say Starbucks and another payment channel for Amazon and so on; one separate channel for each service. That's really problematic. A solution is needed where there is a whole distributed system of payment channels. Then the customer only prepays into that single system. And all the different recipients use the same system. So it would be the same kind of technique with the use of the blockchain with the difference that it would be a whole network of payment channel servers instead of each payment channel being a separate silo. I don't know yet if that's possible to implement in practice though.

[Mightycoin]

I do think that transaction times can be increased, but not upto much extent. The current rates seem ok, unless you are in hurry.

[Anders]

I do think that transaction times can be increased, but not upto much extent. The current rates seem ok, unless you are in hurry.

What is called 0-confirmation transactions can be used for things like buying coffee at Starbucks. Situations like that where the transaction times need to be just a few seconds. I'm thinking of Bitcoin as a system that can handle all (or at least most) forms of currency transactions, including very stressful shopping and other payment situations where transaction times of a few seconds are desired or even demanded.

But, then there is another problem and that is a too bloated block chain. Imagine if bitcoin became mainstream with as many transactions per second globally as Visa. In theory a slight adjustment of the Bitcoin protocol may be able to handle such large amounts of transactions, while in practice it may be too much to handle.

And also, small bitcoin transactions would have a very high fee, percentage wise.

A payment channel system would take care of both the problem of slow transactions and a potential future very high transaction rate.

[evanito]

I think the experienced bitcoin people are the ones that really understand why this isnt a viable solution to the transaction times, which are not actually a high level problem.

[CryptoHeaven]

At present, transaction time is faster than before and I don't think it would increase more soon.

[valvalis]

I dont really like the 10 minutes. its too long. Sometimes it can take even more time than that. 5 minutes is fine but 1 minute would be optimal for me.

Yeah 10 minutes is too long, but sometimes It takes more than 15 minutes for confirmation.
We're really need faster confirmation time.

[bitcoinbeliever]

The idea that third-party solutions will fix 0-conf... it completely throws the baby out with the bathwater.  Sure, it could work -- Visa works.

But it would no longer be bitcoin.  It would no longer be a global peer-to-peer currency.

There is a third option, aside from third party involvement and shorter block times.  The third option is innovation in the bitcoin consensus system itself.  Economic incentives keep miners following the rules today.  It may be possible to add incentives that lead to 0-conf transactions being very reliable in practice, on a time scale much shorter than 10 minutes.

[gatra]

shorter time between blocks would mean we'd have to wait for more confirmations for the same level of security.
It does help with the 7tx/sec limit and gives more granularity in the level of security that you want, but if you had to wait 20 mins for 2 confs then you'd still have to wait 20 mins for 4 confs or you wouldn't have the same security

I think LTC proved that 2,5 mins can work, (async protocols like stratum helped with the problem of wasting power in old blocks) but I'd recommend against anything lower than that.

[DannyHamilton]

shorter time between blocks would mean we'd have to wait for more confirmations for the same level of security.
- snip -
 if you had to wait 20 mins for 2 confs then you'd still have to wait 20 mins for 4 confs or you wouldn't have the same security

This is often stated, but has been demonstrated not to be true.

Since mining is a random process with a poisson distribution, there is no accumulation of progress that happens between blocks.

6 blocks with a total network hashrate of 1 PH/s is equally secure at 5 minute intervals, 10 minute intervals, or 20 minute intervals as long as there is no network latency and all participants can handle the bandwidth requirements.

[gatra]

shorter time between blocks would mean we'd have to wait for more confirmations for the same level of security.
- snip -
 if you had to wait 20 mins for 2 confs then you'd still have to wait 20 mins for 4 confs or you wouldn't have the same security

This is often stated, but has been demonstrated not to be true.

Since mining is a random process with a poisson distribution, there is no accumulation of progress that happens between blocks.

6 blocks with a total network hashrate of 1 PH/s is equally secure at 5 minute intervals, 10 minute intervals, or 20 minute intervals as long as there is no network latency and all participants can handle the bandwidth requirements.

demonstrated? how?

I understand the Poisson process, but: if you want to double spend in a network that uses 6 confirmations, and it has 10 min intervals you must sustain your attack for an hour (in average). If it had 5 min intervals, then sustaining your attack for 30 minutes is enough. So the costs of your attack (if you rent hashrate per time) are halved.

Also, more blocks per hour mean more chances to attack per hour. Imagine that you achieve 25% hashrate. This is not the 51% required to be certain that your attack will succeed, however with 25% hashrate there is a probability that you can eventually find 6 blocks in a row before the network does and perform a double spend. Now let's say that 25% means that you need in average N blocks before you succeed (I'm too lazy to do the math but it should be around 5000 blocks). So if you can attack once every, let's say 5000 blocks, then you can successfully attack about once in a month at 10 minutes per block. But at 5 minutes per block, your ETA ("estimated time to attack") is halved to around 15 days.

so they're not "equally secure"

[DannyHamilton]

shorter time between blocks would mean we'd have to wait for more confirmations for the same level of security.
- snip -
 if you had to wait 20 mins for 2 confs then you'd still have to wait 20 mins for 4 confs or you wouldn't have the same security

This is often stated, but has been demonstrated not to be true.

Since mining is a random process with a poisson distribution, there is no accumulation of progress that happens between blocks.

6 blocks with a total network hashrate of 1 PH/s is equally secure at 5 minute intervals, 10 minute intervals, or 20 minute intervals as long as there is no network latency and all participants can handle the bandwidth requirements.

demonstrated? how?

I understand the Poisson process, but: if you want to double spend in a network that uses 6 confirmations, and it has 10 min intervals you must sustain your attack for an hour (in average). If it had 5 min intervals, then sustaining your attack for 30 minutes is enough. So the costs of your attack (if you rent hashrate per time) are halved.

Also, more blocks per hour mean more chances to attack per hour. Imagine that you achieve 25% hashrate. This is not the 51% required to be certain that your attack will succeed, however with 25% hashrate there is a probability that you can eventually find 6 blocks in a row before the network does and perform a double spend. Now let's say that 25% means that you need in average N blocks before you succeed (I'm too lazy to do the math but it should be around 5000 blocks). So if you can attack once every, let's say 5000 blocks, then you can successfully attack about once in a month at 10 minutes per block. But at 5 minutes per block, your ETA ("estimated time to attack") is halved to around 15 days.

so they're not "equally secure"

True, regardig your first point, it does depend on what you are trying to secure against.  My statement assumed that the attacker owned and controlled the hash power rather than renting it.  I'm not sure that renting hash power is a viable attack strategy, but if it is then you are correct in pointing out that it would cost more to rent the hash power for a longer period of time.

On the other hand, regarding your second point, while a shorter block interval might mean that an attacker with less than 50% of the hash power would have more opportunities to attempt an attack, it doesn't alter the fact that for any given transaction secured by 6 confirmations, the odds of that particular transaction being reversed after 6 confirmations doesn't change based on block interval.

[gatra]

On the other hand, regarding your second point, while a shorter block interval might mean that an attacker with less than 50% of the hash power would have more opportunities to attempt an attack, it doesn't alter the fact that for any given transaction secured by 6 confirmations, the odds of that particular transaction being reversed after 6 confirmations doesn't change based on block interval.

agreed that the odds of a reversal are calculated based on number intervals independently of the duration of those intervals. However my point is that since there are more opportunities if intervals are shorter, the odds of it actually happening in a given timeframe are higher (which is what matters to users: probability of problems in a given timeframe, not for a given number of intervals).

[kjj]

The idea that third-party solutions will fix 0-conf... it completely throws the baby out with the bathwater.  Sure, it could work -- Visa works.

But it would no longer be bitcoin.  It would no longer be a global peer-to-peer currency.

Why do so many people believe this?

There are risks inherent in transactions, for all parties.  Why do so many people insist that it is wrong to use third parties to manage those risks?

I get it that credit card companies are reviled, and for good reasons.  But bitcoin removes the power imbalance that allows them to act in ways that earn our ire.  If they want to continue to exist, they will have to provide valuable services at reasonable costs.

The bitcoin blockchain is global and public.  Do you really think it is necessary that all transactions, no matter how trivial, must be in it?  Keep in mind that we have absolutely no clue how much it really costs to maintain the blockchain, and we won't know for many years.  I suspect that all of our estimates are very, very low, and eventually we will realize that trivial transactions are just too expensive to store publicly.

[instagibbs]

The idea that third-party solutions will fix 0-conf... it completely throws the baby out with the bathwater.  Sure, it could work -- Visa works.

But it would no longer be bitcoin.  It would no longer be a global peer-to-peer currency.

Why do so many people believe this?

There are risks inherent in transactions, for all parties.  Why do so many people insist that it is wrong to use third parties to manage those risks?

It's like saying that you expect your friend to not double-spend against you, so that is against the spirit of Bitcoin. Very silly.

[Mars not Moon]

I dont really like the 10 minutes. its too long. Sometimes it can take even more time than that. 5 minutes is fine but 1 minute would be optimal for me.

Appreciate the way it is bitcoin rocks well in the original state satoshi made it to be.I am no complaints regarding the transactions times

[Dabs]

Really, for most uses I see right now involving bitcoin and the most popular payment processors, I don't see much of a problem with the way it works.

It's not meant for fast food, but it can be accepted. I don't think some black hat is going to waste time attempting a double spend for his fries and burger.