From a site that swaps unconfirmed coins for confirmed coins. That is not at all the majority of merchants.
The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.
sigh... I didn't want to mention what exactly who I exploited precisely because the network is public.
I don't understand why you assert that the attacker doesn't need a bunch of machines. They still need to mine.
You sure you understand the attack? You don't need to mine at all to pull it off. Email me if you want further clarification.
Only confirmation is persuasive evidence of eventual confirmation.
This is circular.
No it's not. Because clients validate all transactions in blocks against the same rules whether the tx is in the most recent block, or how ever many blocks back, the rules for confirmation are the rules for subsequent confirmation. The rules for every single node on the network are exactly the same; if they aren't you get a network split.
On the other hand there is no single set of rules that decides if a transaction will get into a block in the first place; that's up to miners and the relay-rules of the network itself and every miner and every node can, and does, have somewhat different rules they operate by. Some miners ignore satoshidice tx's, other miners ignore zero fee tx's; it's all over the place.
What we have with the Bitcoin community today is people using APIs that don't make it easy to do accurate risk analysis. Of all transactions, not just unconfirmed. For instance the current best practice is to wait some number of blocks before considering a transaction "done" but the actual hardware cost of mounting an attack doesn't depend on the number of blocks, it depends on how difficult those blocks were to create (yes, I'm oversimplifying a bit). So really sites should think about confidence in terms of gigahashes of work done, but in practice no sites actually do. I've tried to support this kind of approach in bitcoinj, where you can query any wallet transaction to find out how much work has been done on top of it, but I never had time to really push this idea.
I'm not one of the core dev's, so maybe they think otherwise, but I'm pretty sure they'd agree that building API's to allow zero-conf transactions to be accepted "safely" sounds like a world of hurt. It's a moving target for one thing as attacks are discovered, and in addition the best ways of detecting them can't be done unless you have access to many different nodes to do network propagation measurement.
If you want to allow zero-conf tx's to be accepted safely, start a
service to do so. Have staff that maintain this service, do constant risk analysis and continual threat detection, and if you have good reason to believe your counter-measures are adequate, offer insurance on transactions using the service. It's not a new idea, but there isn't anyway doing it right now as far as I know, so maybe you can make it work?
Putting this functionality in the satoshi client just leads people to believe the functionality works properly. It'll just lead to more examples of people getting defrauded, and we don't need that.
So it's up to us, the community, to build APIs that ensure users can use Bitcoin safely.
The API's already let you use Bitcoin safely: just don't accept unconfirmed transactions.
Like I said, I'll post the full details in a week or two. As you note yourself, not every site can be contacted manually. Besides anyone who wants to can figure out what you're talking about just by looking at recent changes to various client apps anyway.
It'd be nice of you to ask the core-devs and other members of the community about when is right to release the full details. In addition, when that time comes, I think it'd also be nice to let me do it.
