Quote from: Tirapon on March 13, 2013, 03:45:19 PM

Quote from: piramida on March 13, 2013, 03:22:48 PM

Basically, having to wait for 6 confirmations is already long enough to barely make it useable, and it turns out this is not (always) enough and it could fail due to a simple bug. Call it FUD if you like, but this is bad news, no matter how you spin it.

The way I see it, if the transaction is large enough to make it worth attempting a double spend, then the parties involved ought to be willing to wait for the full 6 confirmations in the interest of security. For smaller transactions, it would not be worth attempting a double spend due to the low success rate and the time and effort required.

Also:

Quote from: oakpacific on March 13, 2013, 03:15:24 AM

In fact, you could easily implement a fork-detection system: whenever a fork(i.e., two branches with more than one block) is detected, wait for more confirmations until one branch stops growing, this is not something requires protocol overhauling or even client reprogramming.

Yes, this is a solution, but a solution which still needs implementing and definitely can't be recommended to financial institutions. Point of reference would be nice here, maybe a service that implements it which could be asked via API for a blockchain health status, or a method in the client that estimates how many confirmations are needed to be "totally sure". Right now, there's no way to have that assurance out of the box.