Why aren't transactions faster?

[BitchicksHusband]

Can somebody explain to me why:

* Mining isn't 10 times faster (a new block every minute instead of 10 minutes)
* With difficulty 10 times easier
* With 1/10 the payout (like 5 coins instead of 50)
* With 1/10 the blocksize (1/10MB instead of 1MB)

Wouldn't confirmations be quicker but everything else be roughly the same?  I am pretty sure there's a good reason for what Satoshi did.  What am I missing?

Also, wouldn't more miners make money?  The coins would be spread out more.

[1715405638]

1715405638

[1715405638]

1715405638

[1715405638]

1715405638

[1715405638]

1715405638

[1715405638]

1715405638

[1715405638]

1715405638

[wumpus]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

There would also be more orphan blocks, and thus more bandwidth usage and overhead.

See also litecoin (https://en.bitcoin.it/wiki/Litecoin), which does this, but with a factor of 4 instead of 10.

[CIYAM]

Satoshi made some choices pretty much arbitrarily with things like average confirmation time and many alt coins you see tend to have much faster confirmation times (although as pointed out in the post above they are thus arguably not as secure as Bitcoin is because of this).

It's arguable whether the Bitcoin settings are the most effective but it would not be so easy to change them (we are pretty much stuck with what Satoshi chose).

In regards to the block sizes it would actually be less efficient in terms of storage space required to make them a lot smaller.

[BitchicksHusband]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

There would also be more orphan blocks, and thus more bandwidth usage and overhead.

See also litecoin (https://en.bitcoin.it/wiki/Litecoin), which does this, but with a factor of 4 instead of 10.

I didn't realize that this was virtually the only feature of Litecoin (I knew it was one of them).

So an orphan block is a single confirmation that never gets a second confirmation, right?

[wumpus]

So an orphan block is a single confirmation that never gets a second confirmation, right?

An orphan is a block that didn't "make it", because someone else made a longer chain without that block in it.
If blocks are generated more often and require less work on average, there is a larger chance of miners generating longer chains on top of older blocks instead of the latest one. This is due to network latency and variance, after all it's a random process and it's possible to generate two blocks in very quick succession.

In any case - it's simply a choice, a compromise that had to be made. Very fast as well as very slow confirmations would have been worse. But there is nothing magical about the 10 in itself.

[gmaxwell]

1/10th?

It's important to realize that if the rate blocks are being found is not a large multiple of how long it takes for a block to be propagated to and accepted by ~all of the network that the network will start suffering from convergence failures and see enormous reorgs. Even before the point where it would cause convergence failure a block time which is too fast relative to latencies would confer an an advantage to large hashpower consolidations (e.g. attackers).

Reducing the block size has some effect on propagation time, but it doesn't eliminate the effect of network latency.

More frequent blocks would also multiplicatively increase the header costs for SPV nodes. E.g. 10 years of headers would be 400MBytes for 1m blocks than 40MBytes.

[amincd]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

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.

To the OP, one other disadvantage of shorter block intervals is that it encourages centralization by giving miners with faster internet connections a greater advantage.

[BitchicksHusband]

Cool, guys.  That was all very helpful.  Thanks.

[JoelKatz]

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.

Exactly. With a one minute block time, your average time to first confirmation is one minute. With a ten minute block time, it's ten minutes. So if two weak confirmations is enough for you, you can have them in two minutes on average, rather than having to wait ten minutes for one strong confirmation. Arguably, two weak confirmations is at least as good as one strong confirmation.

As noted, there are disadvantages to faster block times, of course.

[rpietila]

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)?

[JoelKatz]

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

I'm assuming you use the best known defenses against the most common attacks. That would mean connecting close to as many mining pools as possible and watching for conflicting transactions. The best known attack would then be a Finney attack. Anyone attempting such an attack would risk losing a block they had just mined, so they're risking 25 Bitcoins. So if the sale value is much less than 25 Bitcoins, the risk is very low. You're not going to risk losing 25 Bitcoins to steal 2.

[rpietila]

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

I'm assuming you use the best known defenses against the most common attacks. That would mean connecting close to as many mining pools as possible and watching for conflicting transactions. The best known attack would then be a Finney attack. Anyone attempting such an attack would risk losing a block they had just mined, so they're risking 25 Bitcoins. So if the sale value is much less than 25 Bitcoins, the risk is very low. You're not going to risk losing 25 Bitcoins to steal 2.

So this is only possible if all of the following coincide:
- Malicious intent
- Access to great hashing power
- Luck
- Opportunity to steal >BTC25
- ...with 100% chance of getting caught if successful.

Hardly my customers...

[CIYAM]

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?
...
So this is only possible if all of the following coincide:

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

[JoelKatz]

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

Yeah, you need to use a variety of defenses to sanely accept zero confirmation transactions. One important thing is to make sure the transaction fee is adequate.

[solex]

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

I'm guessing that also the thrust of the OP is that faster blocks allow for faster transactions at a point of sale, especially physical shops where the customer walks out of the store immediately after paying.

Last month I did my first wave-and-pay transaction on my Visa card, which does not even require require a pin number for small amounts. It took 1 second and was done. There is no way a decentralized cryptocurrency will ever compete with that in terms of waiting for block confirmations. This is why Litecoin's 2.5 minute block time is not a significant benefit.

The solution for immediate sales (zero confirmations) must lie elsewhere. Merchants can accept the double-spend risk as a cost of doing business just as they accept the risk of forged currency or stolen credit cards today. In the future there might be insurance available against double-spends for an annual premium. 3rd-party applications which run on top of the Bitcoin protocol can enable instant confirmations if the customer and merchant both use the same 3rd-party service (this is probably a future role for the CC companies).

[rpietila]

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

Yeah, you need to use a variety of defenses to sanely accept zero confirmation transactions. One important thing is to make sure the transaction fee is adequate.

The main defence is that I know who my customers are. From anonymous strangers, I have taken 2 confirmations for sums up to BTC50 (method: sweeping of private key). Is this prudent enough? (BTC50 is more dollarz than it used to be)

[rpietila]

Merchants can accept the double-spend risk as a cost of doing business just as they accept the risk of forged currency or stolen credit cards today. In the future there might be insurance available against double-spends for an annual premium. 3rd-party applications which run on top of the Bitcoin protocol can enable instant confirmations if the customer and merchant both use the same 3rd-party service (this is probably a future role for the CC companies).

Has any of the merchants ever complained about this supposed risk?  As a merchant I find the risk waywaywaywayway smaller than the variable percent of physical shoplifting.

[solex]

Has any of the merchants ever complained about this supposed risk?  As a merchant I find the risk waywaywaywayway smaller than the variable percent of physical shoplifting.

This is a good question. Has any of the btc accepting shops in Berlin, or the various cafes around the world complained about a successful double-spend against them?

[maaku]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

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. A coin with block coming 10x as quickly would allow you to wait less time for confirmations. It would also be a terrible idea for a whole host of other reasons, many of them mentioned above.

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

I disagree. With 10 second confirmations, the probability of a second block being found before the first block propagated to the majority of mining pools would be *much* higher. The longer the confirmation time, the lower the chance a one-confirmation block will be orphaned.

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

[amincd]

^ Yes there are solutions to get around the confirmation wait, like the one you noted. Another is to use the 'rapidly adjusted micropayment channel' that Mike Hearn and Matt Corallo developed in bitcoinj.

All things being equal however, having less time to first confirmation is still more convenient for the customer and merchant, as there will be situations when these special solutions to get around the block time wait will not be used for whatever reason. It's just that all things aren't equal, and other factors need to be considered in choosing a block time.

[Shawshank]

There is nothing you can do to provide significant protection except wait for a confirmation. Do not trust zero-confirmation transactions, ever*.

Wouldn't it be possible to have the top-10 pools state on their website they will not add double-spent transactions to the blockchain even if its fee is higher than the previous transaction? That would definitely give confidence on all kind of merchants by listening to the network for a few seconds and accept low to medium purchases online and in brick-and-mortar premises. It would also bring down the cost of insurance.

[StarfishPrime]

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

Depends completely on the context and the method of transaction. A coffee shop accepting 0-confirmation transactions using a protocol like OpenCXP will have virtually no chance of a double spend. Ever. Any risk of loss would be far, far lower than the 1-3% average fraud loss for card payments which retailers already accept today (over and above the guaranteed "loss" of 3-5% in fees!).

[maaku]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

[dingrite]

What happens if a miner or miners working on the current block get one transaction and x time later get another transaction which is a double-spend of the first while the block is not yet completed? Do they discard both transactions? Or what?

And what happens if the double spend transaction comes a block later? 2 blocks? 3 blocks? etc...    - I assume in those instances the latter double-spend transaction is simply discarded?


Then what happens if one transaction gets into 1 block by miner A. The double spend transaction gets into 1 block by miner B. If the time difference is not large it's hard to believe either would surrender to the other and both will try to continue their block chain for the time being to try and earn extra 25 BTC.

Just some thoughts I have. The probability of this obviously decreases with every block radically especially because un-involved miners will just go the faster block so the stack is loaded against miner B after just 1 extra block (his chances become nill and he has to go with the herd).

[DeathAndTaxes]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

The proposed replace with fee requires the same outputs.  Of course you could also rip off a coffee shop with counterfeit bills or a stolen credit card.  Would be kinda stupid to go to jail for stolen coffee though.

[StarfishPrime]

Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.

Except that you couldn't, at least not without a significant amount of effort, cost and luck - far disproportionate to any possible gain.

That's exactly the problem that OpenCXP solves.

[maaku]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

[DeathAndTaxes]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend.  

[Peter Todd]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend.  

Nodes do not and can-not drop blocks with the double-spend, which is what matters.

Also ironically the double-spend warning feature proposed for 0.9 will make it trivial for individual miners to choose to adopt replace-by-fee rules, because there is currently no way to prove that a double-spend exists other than by broadcasting the entire double-spend transaction.

[DeathAndTaxes]

OpenCXP does nothing and can do nothing to prevent a double-spend with higher fees from replacing the transaction you agreed upon once you walk out that door.

No the client already handles that very well.  Every node will simply drop the double spend. 

Nodes do not and can-not drop blocks with the double-spend, which is what matters.

Also ironically the double-spend warning feature proposed for 0.9 will make it trivial for individual miners to choose to adopt replace-by-fee rules, because there is currently no way to prove that a double-spend exists other than by broadcasting the entire double-spend transaction.

Well that is why I said tx not block.  Can miners conspire to defraud merchants and thus kill Bitcoin adoption and value and indirectly reduce the very value of the coins they are mining?  Of course.  Will they?  It remains to be seen but on low value txs I don't see the merits.

All forms of commerce CAN involve fraud.  One could counterfeit $1 bills just to steal a lifetime of sodas from soda machines.  It probably isn't worth the cost and risk though.   One could get free coffee from this hypothetical scenario by putting a gun in the face of the cashier and demanding not the money in the till but a free large espresso.  I don't see that happening either.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.
 

[Peter Todd]

Well that is why I said tx not block.  Can miners conspire to defraud merchants and thus kill Bitcoin adoption and value and indirectly reduce the very value of the coins they are mining?  Of course.  Will they?  It remains to be seen but on low value txs I don't see the merits.

Some would argue they are defrauding merchants, others would argue they are staving off the kinds of ill-considered centralization that would apply anti-double-spend rules to blocks as well. (there's no way to do this without in effect lowering the block interval) Or they might point to the legal argument that miners may be held negligent in civil cases for failing to have "enough" bandwidth to avoid being "tricked" into accepting a double-spend rather than the "correct" transaction. Finally some would point to the replace-by-fee "scorched earth" strategy and say that allowing profit-driven double-spends is actually safer for eveyone.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.

Bill acceptors in vending machines are actually quite expensive and complex pieces of technology to keep counterfeiters at bay; they are not easy to fool. Similarly stolen credit cards are a big concern and has driven the industry into pushing for smartcard-style credit cards that are significantly more difficult to counterfeit, although note how the concern there is less so than with counterfeit bills because you don't get change back when you pay by credit-card.

[StarfishPrime]

...

All forms of commerce CAN involve fraud.  One could counterfeit $1 bills just to steal a lifetime of sodas from soda machines.  It probably isn't worth the cost and risk though.   One could get free coffee from this hypothetical scenario by putting a gun in the face of the cashier and demanding not the money in the till but a free large espresso.  I don't see that happening either.

In time merchants will adopt the level of security vs convenience that they see necessary.  Much like how soda machines are wide open to attack by stolen credit cards and counterfeit bills yet have not taken more expensive and intrusive countermeasures there will be a place for 0-confirm transactions.  Note: nothing I said should be taken that all merchants should rush into accepting 0-confirm txs in all scenarios without understanding the risks.
 

^ This. Exactly. Merchants will manage their risks exactly like they do today with credit cards, cash, etc. Once adoption becomes more widespread, statistics will be available to to this.

In almost every case, risks and overall costs should prove to be much lower than existing payment networks. BitPay has reported that in their first 10K transactions, there wasn't a single case of fraud. Compare that with any credit card scenario online or in-person.

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)

If/when the core devs ever implement this it would be a major step toward 'last mile' adoption of bitcoin in retail and we could finally get beyond the discussions of the (mostly hypothetical) double-spend "problem".

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would be likely be considered broken by Satoshi.

[gmaxwell]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:
Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)
If/when the core devs ever implement this it would be a major step toward 'last mile' adoption of bitcoin in retail and we could finally get beyond the discussions of the (mostly hypothetical) double-spend "problem".
Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would be likely be considered broken by Satoshi.

Satoshi made a few serious mistakes, expecting sequence mediated replacement to be usable may have been one of them. Perhaps he realized that and thats why— unlike so many other things— he didn't actually implement it.

There are two major issues with sequence mediated replacement:

First is that it opens a major DOS vulnerability: I start issuing bunches of the largest transactions the network will tolerate, with high fees, locked so they are not going to be mined for the immediate future... but I'll never pay those fees because I'll replace them all before they become due. But until then I'm running every node out of memory pool storage. Any way that closes the DOS attack provides a way for an attacker to help them violate the sequence ratchet.

The second is that it demands all miners behave in a way that reduces their income, perhaps substantially. If I learn of an earlier sequence spend with an child transaction that pays a high fee, why should I continue to attempt to mine the higher sequenced spend?

Miners behaving in their own short term interests against the interests of (some of) the users is not hypothetical, its a reality today.

So far I've not seen or come up with any way of solving the DOS problem, nor any way of solving the incentives problem that works for non-trivial-valued transactions (for trivial valued transactions we could perhaps use the threat of increased orphan risk, but that stops being a solution for high values or if attackers start bribing many miners with chains of fees).

[maaku]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which hasn't been implemented in BitcoinQT but could basically solve the double-spend problem (at least regarding tx replacement) if it was:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX)

Beyond the valid points made by gmaxwell and Peter Todd, you are making one serious mistake in your reasoning: you are assuming that other clients will behave like your client does. The *only* transaction-selection behavior that is enforced by protocol is proof-of-work confirmation of transactions in blocks. You have no guarantees that any other node will handle double-spends the same way you or a future version of the reference bitcoin client does.

Example: a site like blockchain.info tries to connect to every single node on the bitcoin network, and keeps all transactions, including double-spends. If it were configured to forward transactions, or if miners scraped the bc.i update pages for transactions it hadn't seen (a not unlikely possibility), then it does not matter in the slightest what the default relay rules are of the rest of the network. Anyone can perform a double-spend by sending the transaction to bc.i, and one way or another a major mining pool with promiscuous replace-by-fee settings will accept it.

The bitcoin protocol offers absolutely no hard guarantees about consensus until a transaction finds its way into a valid block. Placing any trust in unenforced and unenforceable relay rules is a recipe for disaster.

[StarfishPrime]

...
There are two major issues with sequence mediated replacement:

First is that it opens a major DOS vulnerability: I start issuing bunches of the largest transactions the network will tolerate, with high fees, locked so they are not going to be mined for the immediate future... but I'll never pay those fees because I'll replace them all before they become due. But until then I'm running every node out of memory pool storage. Any way that closes the DOS attack provides a way for an attacker to help them violate the sequence ratchet.

Yes, agreed. I think the implementation of this would need to be constrained and certainly not be open-ended. This could so easily be exploited it must have already been seen as a vulnerability when the spec was drafted.

...
The second is that it demands all miners behave in a way that reduces their income, perhaps substantially. If I learn of an earlier sequence spend with an child transaction that pays a high fee, why should I continue to attempt to mine the higher sequenced spend?

Miners behaving in their own short term interests against the interests of (some of) the users is not hypothetical, its a reality today.

So far I've not seen or come up with any way of solving the DOS problem, nor any way of solving the incentives problem that works for non-trivial-valued transactions (for trivial valued transactions we could perhaps use the threat of increased orphan risk, but that stops being a solution for high values or if attackers start bribing many miners with chains of fees).

The following minor implemention would "fix" the double-spend by higher-fee-replacement scenario: If sequence == UINT_MAX, then the tx 'finality' would be respected (as originally intended per the spec) and the tx would not be replaced by any node - even if replace-by-fee was implemented and the fee was higher.

This would go a long way to reducing any chance of malicious double-spend success, while not increasing DOS vulnerability or affecting other situations where replacement-by-fee could be useful.  

[StarfishPrime]

...
The bitcoin protocol offers absolutely no hard guarantees about consensus until a transaction finds its way into a valid block. Placing any trust in unenforced and unenforceable relay rules is a recipe for disaster.

In an absolute sense, this is of course 100% accurate.
Back in the real-world of retail transactions however, there are no absolutes or guarantees. A 99% (or even 96%) certainty that a tx will eventually confirm is all that would be required to make bitcoin payments on par with existing networks (Visa, MC, or even cash) in terms of the cost/risk exposure profile (which is huge).

Perfect is the enemy of better.

[oakpacific]

What about asking customers to use only one-time addresses(could be several addresses with fixed denominations or just a round number which is larger than the purchase sum, changes will be sent back later to a designated address by the merchant), whose private keys will be submitted to the merchant at time of payment, so that if the buyer conducts any further foul plays, the merchant could do the same.

[callem]

What about asking customers to use only one-time addresses(could be several addresses with fixed denominations or just a round number which is larger than the purchase sum, changes will be sent back later to a designated address by the merchant), whose private keys will be submitted to the merchant at time of payment, so that if the buyer conducts any further foul plays, the merchant could do the same.

OpenCXP does similar to what you describe, sends back change to the customer and has control of both the fee amount and transaction broadcast latency time, greatly reducing the already very low risk of a successful double spend.

Any implementation of replace-by-fee that doesn't follow the bitcoin specification by respecting tx sequence is broken. This wasn't a mistake by Satoshi, it was his solution for entirely optional tx malleability.

A broken implementation would be disastrous for bitcoin. It would make fraud through double spending trivial by undermining tx irreversibility and damaging the already fragile confidence in bitcoin as a payment system.

Again - it would be disastrous. Remember, double spends are not a trivial peripheral issue. They are the very core issue that bitcoin solved.