Why aren't transactions faster?

[gmaxwell]

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation.

Depends on the threat that you're talking about. For example, the cost of a finney attack in the 10 second model is _much_ _much_ lower. If you're just taking about the accidental reorganization probability _and_ the network latency is negligible compared to both numbers (uh, wouldn't be for 10 seconds), then thats another matter.

[JoelKatz]

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation.

Depends on the threat that you're talking about. For example, the cost of a finney attack in the 10 second model is _much_ _much_ lower. If you're just taking about the accidental reorganization probability _and_ the network latency is negligible compared to both numbers (uh, wouldn't be for 10 seconds), then thats another matter.

I don't think it has any effect on the Finney attack except to give you more options. With 10 second confirmations, the equivalent to a Finney attack on Bitcoin would be to wait until you were six blocks ahead of the public chain. Since the difficulty would be one-sixth, it should be just as likely to happen. This was discussed on Bitcoin.SE a while ago:
http://bitcoin.stackexchange.com/questions/1192/would-a-reduced-block-generation-time-make-the-finney-attack-more-difficult

[gmaxwell]

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation.

Depends on the threat that you're talking about. For example, the cost of a finney attack in the 10 second model is _much_ _much_ lower. If you're just taking about the accidental reorganization probability _and_ the network latency is negligible compared to both numbers (uh, wouldn't be for 10 seconds), then thats another matter.

I don't think it has any effect on the Finney attack except to give you more options. With 10 second confirmations, the equivalent to a Finney attack on Bitcoin would be to wait until you were six blocks ahead of the public chain.

You may note that I'm responding to Maaku claiming that 1 confirm on λ=1/10  is as secure as 1 confirm on λ=1/600.

[JoelKatz]

You may note that I'm responding to Maaku claiming that 1 confirm on λ=1/10  is as secure as 1 confirm on λ=1/600.

Oh, sorry, lost the context. Well, I hope what I posted is useful to someone.

[oakpacific]

If there is a limit on the rate of growth of the blockchain size, then I guess no matter what confirmation time you use it's going to be all the same?

Also, I doubt if shorter confirmation time block really has the merit of adjustable security-security here is something binary, you are either completely screwed or completely fine, one successful double-spend is enough to do much damage to people's confidence in Bitcoin, so we better stay on the conservative side.

[amincd]

But it gives you the option of accepting a transaction that has 1/10th the security of a 10 minute block if you can afford to sacrifice some security for greater speed, but not to the point of accepting a zero confirmation transaction.

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?

Like JoelKatz noted, if the proper precautions are taken, it's very low. However, it costs nothing for a miner to attempt a double spend by replacing a transaction, so in cases where the payer is interacting anonymously and remotely with the payee, and deposited funds can be withdrawn at no cost, double spends can be attempted at no risk to the payer, and numerous attempts can be made until one finally succeeds.

For that reason, if you're a web service that allows for instant transfer of goods to the payer, upon receipt of bitcoins, like an e-wallet or an exchange, you would need to wait at least one confirmation before accepting deposits, and in this case, a shorter block time would have an advantage.

[maaku]

I should have chosen a better lower bound than 10s, because yes at that scale network propagation has measurable effects on the security. But a 1-minute confirm would not be significantly less secure than a 10-minute confirm (and a 2-week confirm wouldn't be much more secure than that).

Zero-confirmation transactions have no security beyond your trust in the person you are interacting with. Full-stop.

[jdbtracker]

I should have chosen a better lower bound than 10s, because yes at that scale network propagation has measurable effects on the security. But a 1-minute confirm would not be significantly less secure than a 10-minute confirm (and a 2-week confirm wouldn't be much more secure than that).

Zero-confirmation transactions have no security beyond your trust in the person you are interacting with. Full-stop.

I don't quite understand how a double spend works. If you pay for something both your wallet and their wallet will have funds immediately updated... all that the network is doing is keeping a snap shot of a moment. I guess the risk of the double spend may come from someone else who's client has not been updated yet as in a duplicate wallet operating from a remote area, because I'm pretty damn sure everyone running a wallet near-by would have their wallets updated as well, so you couldn't just run next store down and spend more, from that point on your going up to luck which of these transactions will reach the mining pool first? The earliest one wins, so I guess it is more of a problem with online retailers... you never know someone could have 500 duplicate wallets strategically spread around the world ready to buy a digital service simultaneously.
Otherwise you have 10 seconds to do your double spend somewhere on the planet before the first one reaches around the globe, then again you could have collaborators ready to buy subway sandwiches at the same moment in time around the globe, from which only one person payed.

[gmaxwell]

I don't quite understand how a double spend works. If you pay for something both your wallet and their wallet will have funds immediately updated...

A bad-guy is not required to play by your rules, he can issue spends although he knows better simply because its physically possible to do so.

[amincd]

Why this discussion is relevant:

Next week I'm giving a presentation and answering questions on Bitcoin to a group of CEOs, several of them Fortune 500, including the CEOs of two of the top five PoS system providers. Please feel free to tell me anything that's on your mind... (self.Bitcoin)

The submitter stated in a comment:

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

A 1 versus 10 minute wait for an internet purchase could be significant.

[rpietila]

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

I think the submitter is not even close to thinking like a large retailer. What if everybody would just think with their own brains..

[oakpacific]

Why this discussion is relevant:

Next week I'm giving a presentation and answering questions on Bitcoin to a group of CEOs, several of them Fortune 500, including the CEOs of two of the top five PoS system providers. Please feel free to tell me anything that's on your mind... (self.Bitcoin)

The submitter stated in a comment:

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

A 1 versus 10 minute wait for an internet purchase could be significant.

There is an alternative I think, you first check if the sender's address has unconfirmed transactions, then wait a few seconds for propagation time, then for small-time purchase you can just deliver the goods, as race attack would have been infeasible and only Finney attack would work.

Besides, for online purchase of physical goods, there is no need to worry about confirmation time, since you have evidence for double spending, you can always refuse to deliver.

[StarfishPrime]

Why this discussion is relevant:

Next week I'm giving a presentation and answering questions on Bitcoin to a group of CEOs, several of them Fortune 500, including the CEOs of two of the top five PoS system providers. Please feel free to tell me anything that's on your mind... (self.Bitcoin)

The submitter stated in a comment:

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

A 1 versus 10 minute wait for an internet purchase could be significant.

Whatever the background for the reddit submitter's post (the 'fortune 500 ceo's' scenario sounds slightly implausible), there is a good discussion going on over there.

There's no way btc is ready for primetime at big box retail using any current solutions. Coinbase or BitPay could undoubtedly rise to the challenge using their proprietary back-ends, but it would need to be integrated into their existing POS infrastructure (no small task, but it could be done).

Likely they would test the water with online sales (easy) and gift cards paid in btc (also easy). We're a long way off from in-store btc for major retailers.

For a discussion from a merchant perspective of comparative risks and costs between bitcoin and credit/debit cards etc at POS, the preliminary whitepaper at www.openCXP.org shows that bitcoin transaction times are more of a theoretical than practical issue for retail implementation. (OpenCXP is currently at RFC "request for comment" stage).

[Phrenico]

The orphan argument is a good reason to be skeptical that a <1 minute/block average is best. Litecoin has shown us that going from 10 minutes to 2.5 does not significantly increase the orphan rate.

And even if it does, the likelihood of your transaction being orphaned after four 2.5 minute blocks is less than it would be after one 10 minute block.

Couple that with the stronger security from deliberate attacks, it seems to me that 2.5 minute blocks is a win. It simply doesn't make sense to be complacent with the current level of security when an improvement has been recognized and tested.

[DeathAndTaxes]

The orphan argument is a good reason to be skeptical that a <1 minute/block average is best. Litecoin has shown us that going from 10 minutes to 2.5 does not significantly increase the orphan rate.

So far.  LTC still has negligible tx volume.  Even stupidly fast scamcoins with 30 second blocks are usually fine when blocks are essentially nothing more than a single coinbase transaction.  The goal however would be for the network to scale to hundreds of maybe even thousands of transactions a second.   Also the average block time is somewhat misleading. Mining is a possion process and the block times are going to be distributed around the average.  A not insignificant fraction are going to be significantly less than the average.

LTC may be fine or it may not we will have to see but I agree there likely is an optimal block interval and it makes the coins with ultra short block intervals of dubious value.

[DeathAndTaxes]

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

I think the submitter is not even close to thinking like a large retailer. What if everybody would just think with their own brains..

This.  By that logic no company would even consider taking credit cards.  The fraud risk of credit cards is NEVER (I mean absolutely under no possible scenario never) 0% even if you properly train employees, ask for ID (which ironically is a violation of VISA/MC rules), closely analyze the signature, and are an expert at spotting a fake card.  

If the fraud losses due to 0-confirm tx are less than the fraud losses company ALREADY absorb from credit cards then accepting 0-confirm tx would only improve the bottom line.  0-confirm isn't right for every product in every scenario but I think it will be more common that people think.  A company brokering priority access to blocks (possibly repaying pools for x tx per block) along with a contract with the pools to not substitute competing double spends could likely clean up by providing a service to merchants who need 0-confirm protection.  Will the fraud losses be zero?  Probably not but they don't have to.   Especially for online merchants where CC fraud (and mitigation costs) is 5% or more on digital goods.    Getting that to "only" 1% would be a windfall for merchants.

[Phrenico]

Also the average block time is somewhat misleading. Mining is a possion process and the block times are going to be distributed around the average.  A not insignificant fraction are going to be significantly less than the average.

Yep. The point that the standard deviation gets relatively bigger with smaller means is well-taken: a single conf is less likely to be orphaned under a 2.5 minute mean than under a 10 minute mean. But what we should really be comparing are the two parameters under equal wait-times.

If you are buying a car with bitcoins and want to do a blockchain transaction, waiting 10 minutes will get you an average of 4 confirmations at 2.5 minutes/block vs. 1 confirmation at 10 minutes/block. The 4 confirmations are better protection against orphan blocks.

What I have been wondering is whether the faster blockrate lowers the threshold for a selfish mining attack. I was going back and forth on this in my head and tentatively think that a slower blockrate is better protection. I might crunch the numbers over thanksgiving. Has this been considered?

[amincd]

Why this discussion is relevant:

Next week I'm giving a presentation and answering questions on Bitcoin to a group of CEOs, several of them Fortune 500, including the CEOs of two of the top five PoS system providers. Please feel free to tell me anything that's on your mind... (self.Bitcoin)

The submitter stated in a comment:

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

A 1 versus 10 minute wait for an internet purchase could be significant.

There is an alternative I think, you first check if the sender's address has unconfirmed transactions, then wait a few seconds for propagation time, then for small-time purchase you can just deliver the goods, as race attack would have been infeasible and only Finney attack would work.

Besides, for online purchase of physical goods, there is no need to worry about confirmation time, since you have evidence for double spending, you can always refuse to deliver.

I agree that with the proper precautions (waiting a few seconds to see if there are double spend attempts, ensuring the transaction has a sufficient tx fee) 0-confs is enough for a point of sale transaction.

For online services however, there are two reasons why a faster block time would be an advantage: first, if the service offers withdrawals of bitcoin deposited, then they need to wait for at least one confirmation to ensure you're not withdrawing bitcoins that you double spent. Second, some services want to ship immediately upon the order being placed. Having to wait for a 10 minute confirmation versus a 1 minute confirmation before shipping makes a difference here.

It's also not convenient for a service to have to keep track of which completed purchases are still at 0-confirmations and wait until they have at least 1 before shipping. The merchant could more practically wait for 1 confirmation before confirming the purchase is complete with a 1 minute rather than 10 minute block interval target and avoid the need to wait for a separate 'shipping confirmation' after they've already confirmed the purchase with the customer.

Will the fraud losses be zero?  Probably not but they don't have to.   Especially for online merchants where CC fraud (and mitigation costs) is 5% or more on digital goods.    Getting that to "only" 1% would be a windfall for merchants.

True, however we can look at the real Bitcoin economy to see that not every service will allow 0-conf transactions.

[maaku]

I agree that with the proper precautions (waiting a few seconds to see if there are double spend attempts, ensuring the transaction has a sufficient tx fee) 0-confs is enough for a point of sale transaction.

No, no, and no. None of those precautions you mention do anything to protect you against a double spend. There is nothing you can do to provide significant protection except wait for a confirmation. Do not trust zero-confirmation transactions, ever*.

(* Unless you are extending pre-existing trust you've placed in the person sending the coins, or have some mechanism for obtaining restitution in the case of a double-spend. Either way, that's side-stepping, not solving the problem.)

[oakpacific]

Why this discussion is relevant:

Next week I'm giving a presentation and answering questions on Bitcoin to a group of CEOs, several of them Fortune 500, including the CEOs of two of the top five PoS system providers. Please feel free to tell me anything that's on your mind... (self.Bitcoin)

The submitter stated in a comment:

Large retailers won't take the risk of 0-confirmation transactions, even small ones. It's just a non-starter. Part of the reason I'm there, however, is to fix that.

A 1 versus 10 minute wait for an internet purchase could be significant.

There is an alternative I think, you first check if the sender's address has unconfirmed transactions, then wait a few seconds for propagation time, then for small-time purchase you can just deliver the goods, as race attack would have been infeasible and only Finney attack would work.

Besides, for online purchase of physical goods, there is no need to worry about confirmation time, since you have evidence for double spending, you can always refuse to deliver.

I agree that with the proper precautions (waiting a few seconds to see if there are double spend attempts, ensuring the transaction has a sufficient tx fee) 0-confs is enough for a point of sale transaction.

For online services however, there are two reasons why a faster block time would be an advantage: first, if the service offers withdrawals of bitcoin deposited, then they need to wait for at least one confirmation to ensure you're not withdrawing bitcoins that you double spent. Second, some services want to ship immediately upon the order being placed. Having to wait for a 10 minute confirmation versus a 1 minute confirmation before shipping makes a difference here.

It's also not convenient for a service to have to keep track of which completed purchases are still at 0-confirmations and wait until they have at least 1 before shipping. The merchant could more practically wait for 1 confirmation before confirming the purchase is complete with a 1 minute rather than 10 minute block interval target and avoid the need to wait for a separate 'shipping confirmation' after they've already confirmed the purchase with the customer.

Will the fraud losses be zero?  Probably not but they don't have to.   Especially for online merchants where CC fraud (and mitigation costs) is 5% or more on digital goods.    Getting that to "only" 1% would be a windfall for merchants.

True, however we can look at the real Bitcoin economy to see that not every service will allow 0-conf transactions.

Actually, if we have a user-friendly multisignature implementation, a possible recourse for online retailers could be this:

(1). ask the buyer to deposit/charge a certain amount of Bitcoin balance to an 2-of-2 address, should be enough for a month or two's purchase, this transaction must have enough confirmations to be valid;

(2)  the buyer should also leave an "exit address" for refunding;

(3) whenever the buyer wants to make a purchase, he could only spend from this address, or he has to wait for confirmations, every transaction from this address thus has to be signed by both the buyer and the retailer, in a user-freindly way;

(4)when the user requires a complete/partial refunding , both parties would sign the transaction to the 'exit address" described above.

This should allow enough security while greatly reducing the inconvenience.

Better still, if the user frequently purchase online, but not just in one single shop, he could put his bitcoins into an address multi-signed with an online payment processor, which handles payment processing for lots of merchants, the advantage over old school payment processor is they can't move your bitcoins elsewhere without your approval.