Topic: Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch - page 5. (Read 18314 times)
April 19, 2013, 03:03:11 PM
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".
April 19, 2013, 02:19:35 PM
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.
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.
April 19, 2013, 02:09:54 PM
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?
April 19, 2013, 01:04:19 PM
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.
Quote from: Mike Hearn
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
April 19, 2013, 12:54:56 PM
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.
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.
April 19, 2013, 11:58:13 AM
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.
April 19, 2013, 11:49:30 AM
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.
April 19, 2013, 11:46:33 AM
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.
April 19, 2013, 11:25:57 AM
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? April 19, 2013, 11:17:10 AM
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.
April 19, 2013, 11:14:23 AM
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.
April 19, 2013, 11:03:26 AM
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.
April 19, 2013, 10:32:55 AM
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)
April 19, 2013, 10:29:37 AM
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?
I don't see any reason why it wouldn't be safe, or is there something I'm missing?
April 19, 2013, 10:25:28 AM
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?
April 19, 2013, 10:16:09 AM
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.
April 19, 2013, 09:52:54 AM
It is proven they are not safe today, ignoring any proposed changes.
Not safe compared to what?Most merchants out in the real world already accept payment methods that can be trivially reversed and manage to make it work.
Not safe compared to how safe people think they are, of course.
April 19, 2013, 09:40:26 AM
It is proven they are not safe today, ignoring any proposed changes.
Not safe compared to what?Most merchants out in the real world already accept payment methods that can be trivially reversed and manage to make it work.
April 19, 2013, 09:38:18 AM
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.
April 19, 2013, 08:57:10 AM
1) Go to the counter
2) Get a Whopper®
3) Pay with bitcoin
4) Go out
5) Attempt a double-spend, now both txs are removed from the pool
6) Enjoy your meal
2) Get a Whopper®
3) Pay with bitcoin
4) Go out
5) Attempt a double-spend, now both txs are removed from the pool
6) Enjoy your meal
It seemed like a good idea, at the time
. Jump to: