Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch

[meowmeowbrowncow]

Not at all, and you have the invention of ASICs to thank for that. Mining now requires a large up-front investment that would be completely useless if Bitcoin were to collapse

Come on, you must admit that some double-spent of 0-conf transactions would never make Bitcoin collapse, that's an exaggeration. Particularly if people understand that a 0-conf tx can be easily undone.

More to the point, zero-conf transactions have been double-spent already.  It is proven they are not safe today, ignoring any proposed changes.

Exactly.  Why are we arguing about 0 conf tx?  They are unsafe to begin with.


wtf? 

[warpio]

Question: Would just 1 confirmation be safe if you were to confirm it yourself on your own local copy of the blockchain? Would you not need to wait for 6 confirmations in that case?

I don't see any reason why it wouldn't be safe, or is there something I'm missing?

[caveden]

I am not aware of any merchant that has ever been double spent with 0-conf transactions except the OKPAY example during the chain split.

OKPay was not victim of a 0-conf, but a much more serious situation (the huge reorg caused by the 0.7 bug).
I think at least Satoshi Dice has already been the victim of a 0-conf double-spend.
But yeah, they are rare to the point of being negligible, if you compare them with CC fraud.

That doesn't change OP's point though: it's only safe because most miners are behaving as per the default bitcoind implementation. There's no strong guarantee that will remain being the case for long. (even then 0-conf would still remain relatively safe for many use cases, for example when you know your customer or when you can suspend your service easily)

[Mike Hearn]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth. Doing things that significantly reduce the utility of the system is self-defeating even over the medium term because it'd lead people to just give up on the system in disgust and sell their coins, driving down the price. I think it's fair to say that being unable to buy basic things like food or drinks in person would reduce the utility of Bitcoin for a lot of people.

[xanatos]

What happens if a block becomes orphan? Its transactions are readded to the transaction pool, so they could be changed by the sender... So you would only need to wait for a split in the network to double spend your money?

I've never analysed the data myself, but I'd guess that honest splits tend to carry almost (if not exactly) the same transactions on each side of the split.

They probably collect the transactions in a "best effort" way... But if 2 blocks are orphaned, perhaps you can't put all their transactions in a new block.

[jgarzik]

I am not aware of any merchant that has ever been double spent with 0-conf transactions except the OKPAY example during the chain split. Which was almost certainly caused by mining nodes being restarted and not syncing their mempools - quite easy to fix.

SatoshiDICE has been double-spent.  There are other incidents as well.

[justusranvier]

SatoshiDICE has been double-spent.  There are other incidents as well.

Does the rate of incidents as a fraction of total transactions compare favorably or unfavorably to the rate of reversed transaction typical to credit and debit cards?

[Peter Todd]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth.

Similar to how rational coal power plant operators and chemical plant owners wouldn't want to undermine the cleanliness of the air they breath and water they drink.

[Peter Todd]

SatoshiDICE has been double-spent.  There are other incidents as well.

piuk has said that the blockchain.info send-shared mixer has been double-spent a few times.

[d'aniel]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth.

Similar to how rational coal power plant operators and chemical plant owners wouldn't want to undermine the cleanliness of the air they breath and water they drink.

Eh?  The cleanliness of the air they breathe and water they drink doesn't affect their bottom line.

[Mike Hearn]

Yeah, the blockchain thing was long chains of transactions that wouldn't confirm for ages and then relying on mempool churn to replace one of them along the way.

I don't see any need to change Bitcoin here. If you don't think 0-conf txns are reliable, OK, wait for a block. Or tell people who will listen to wait for a block. Those who want to see how reliable they can be made using technical fixes like mempool sync, doublespend alerts, risk analysis and so on can then go ahead and do so. The market will end up deciding who is right. If merchants keep getting double spent they'll go to waiting for a block. If they don't, then we all win with a more useful currency.

[amincd]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth.

Similar to how rational coal power plant operators and chemical plant owners wouldn't want to undermine the cleanliness of the air they breath and water they drink.

If a coal power plant operator controlled 20% of the coal plants in the world, they might be concerned, as there would be a measurable effect on their health from them choosing a more polluting way to burn coal. This is comparable to the impact that the decisions of mining pool operators have.

Now regardless of the wisdom of trusting 0-conf transactions, the fact remains that no one is forced to accept them, and removing the option by a deliberate change in standard client rules is leaving people who would otherwise choose to risk a double spend on a 0-conf transaction without the option to do so. How can that be rationalized? "We know what's best for merchants" isn't a compelling argument.

By all means, warn merchants that 0-conf transactions can be double spent, and explain the methods an attacker could use, but still let them choose what level of risk they want to bear.

I don't see any need to change Bitcoin here. If you don't think 0-conf txns are reliable, OK, wait for a block. Or tell people who will listen to wait for a block. Those who want to see how reliable they can be made using technical fixes like mempool sync, doublespend alerts, risk analysis and so on can then go ahead and do so. The market will end up deciding who is right. If merchants keep getting double spent they'll go to waiting for a block. If they don't, then we all win with a more useful currency.

+1

[caveden]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth.

But they wouldn't be undermining their own wealth, I'd say the contrary actually.

Doing things that significantly reduce the utility of the system is self-defeating even over the medium term because it'd lead people to just give up on the system in disgust and sell their coins, driving down the price.

You're being overly dramatic here, admit it. Being able to replace 0-conf tx would not be such a bad thing.
I'd say that "selling" a false impression of security could actually do more damage. And the fact is that 0-conf are, by definition, replaceable.

I think it's fair to say that being unable to buy basic things like food or drinks in person would reduce the utility of Bitcoin for a lot of people.

But they'd still be able to do it.
First, if the merchant knows his/her customer, no major problem in accepting 0-conf.
If he doesn't, still, he can rely on insurance contracts that will on their turn have miners committing to mine a particular transaction instead of any replacement.
Besides that, merchants could also collectively - and voluntarily - try to blacklist double-spenders.
Sums all that, and you'll have very little fraud, if any.

Actually, why am I telling all these things to you? All these ideas are yours after all... hum... Friday evening, you're already drinking or something?

[Mike Hearn]

0-conf transactions aren't replaceable by definition. The definition is the source code and it drops double spends against the memory pool. That's the whole point - peter wants to change the definition of what a zero-conf transaction means.

All the things I suggested for ways to improve the security of unconfirmed transactions are still valid, but they obviously assume the system isn't trying to actively undermine you.

Like I said, what's the downside to being laissez-faire about this? Live and let live. The market will sort it out.

[caveden]

What you're calling "definition" is a set of "good practices" implemented in bitcoind and followed by most (all?) miners. But the protocol itself allows for 0-conf replacements. That's what I meant by "definition".

[im3w1l]

Retail will want transactions satisfying:

Time to verify: < 10 seconds
Risk of charge-back/double spend: < 1%

If we change 0-conf double spends from possible to trivial, it will no longer be possible to satisfy those constraints with bitcoin.

[kjj]

Retail will want transactions satisfying:

Time to verify: < 10 seconds
Risk of charge-back/double spend: < 1%

If we change 0-conf double spends from possible to trivial, it will no longer be possible to satisfy those constraints with bitcoin.

The problem is that it isn't up to us.  There is no "we".  No one on the entire planet has the ability to prevent miners from picking transactions according to their own criteria.  If anyone is making assumptions about transactions that are not backed by actual, verifiable work, they are doing it wrong, and it is only through good fortune that they haven't been burned yet, assuming that they haven't been burned already.

[im3w1l]

The problem is that it isn't up to us.  There is no "we".

There is a "we". We who want BTC to be usable as a you know, currency.

No one on the entire planet has the ability to prevent miners from picking transactions according to their own criteria.

We can change their incentives. Bubbleboy posted a very nice proposal. See: https://bitcointalk.org/index.php?topic=180640.0

[unk]

There's no guarantee, but Satoshi's paper addresses the dynamics of this - rational miners shouldn't want to undermine the validity of their own wealth. Doing things that significantly reduce the utility of the system is self-defeating even over the medium term because it'd lead people to just give up on the system in disgust and sell their coins, driving down the price.

i believe this is an analytical error that i've tried to correct many times before. for one thing, it ignores dynamic market effects (for example, someone who profits from a put option, a short sale, or even a regular sale). it is usually a mistake to predict too confidently what 'rational' parties will do based on an incomplete understanding of their behaviour.

[Maged]

Retail will want transactions satisfying:

Time to verify: < 10 seconds
Risk of charge-back/double spend: < 1%

If we change 0-conf double spends from possible to trivial, it will no longer be possible to satisfy those constraints with bitcoin.

The problem is that it isn't up to us.  There is no "we".  No one on the entire planet has the ability to prevent miners from picking transactions according to their own criteria.  If anyone is making assumptions about transactions that are not backed by actual, verifiable work, they are doing it wrong, and it is only through good fortune that they haven't been burned yet, assuming that they haven't been burned already.

There is a "we": society. No one on the entire planet has the ability to prevent people from walking around naked. And yet, people don't walk around naked in most public locations. Sure, there are pockets of areas where this happens, but if you were randomly teleported to a populated area, you can reasonably calculate the risk of seeing naked people. Of course, you'll say that this only happens because people are being threatened with force by a government. However, governments are merely a social construct, so that argument doesn't really apply. Where it does apply, though, is when you bring up the argument that governments make it harder bring forth social change. Which brings up my next point: because of the power Bitcoin-Qt currently has, adding this change by default is very likely to be successful if you can convince the core developers. 0-conf transactions would become impossible to use in any even slightly untrusted scenario, and miners go forward with the understanding that it is socially acceptable to put personal profits first (in bitcoin, not necessarily fiat at that point). Because miners have been conditioned to only think of themselves, and society agrees, it might become socially acceptable to centralize mining. After all, that is the most profitable (again, it bitcoin) future for miners. Once you control over 50% of the mining power, you get to say who is allowed to produce blocks and who isn't, thus preventing competition from undercutting them by allowing lower transaction fees and making more money individually in the short-term. What behavior we make as default in the client now is very likely to persist for quite some time because of this effect.

Therefore, let me clarify my earlier statements: it's fine (and actually great!) that you make this patch and allow people to use it. The market should be allowed to make that decision. But, we should not force it by making it the default in the client, especially because it would be hard to go back to the way things are, much like how you can't stop centralized mining once it is in the majority.