A successful DOUBLE SPEND US$10000 against OKPAY this morning.

[00ph8al]

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.

[jl2012]

ok, if you guys think it is not "double spend", let's call it "reversed transaction". That's not the main point here.

what happened is that businesses did not update the clients

Actually the opposite is true. OKPAY got cheated because they were using the latest client (0.. If they did not update, they would never see the original transaction confirmed.

[RodeoX]

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.

Maybe your right? Please point me to a double spend.

[Syke]

Because this required a fork, I don't think there's anything that can be done. I mean, the entire system of bitcoin relies on forks not occurring. I'm no Dev though, so don't take my word as law.

Good thing you added that last line, because you are dead wrong. Forks are expected. They will always happen. That is a core feature in how Bitcoin is designed.

[Joshuar]

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

[skooter]

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

yeah you're wrong.

Forks happen anytime 2 miners solve a block referencing the same previous block.

[b¡tco¡n]

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

yeah you're wrong.

Forks happen anytime 2 miners solve a block referencing the same previous block.

But usually one of the forks gets chosen by consensus right? And after 6 of so confirmations it is extremely unlikely to change.

When this thread was opened there was a bug (or bug fixed) with the latest version of the software which means that the new version of the software chose a different branch to the old, which is a very different and horrible problem. IIRC the developers told people to downgrade to the old version and the associated fork became the chosen fork, and thus losing transactions made in the unchosen fork.

Hammer me if this isn't 100% accurate but I think it is the gist.

Usually forks are OK and get resolved. This thread is about a different 'hard' fork cause by software issues.

[Meuh6879]

How serious is this please. Double spends  I thought were impossible .

it's impossible.
when you wait the 1 confirmation (1 block) ... anyway. 

[Maged]

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem?

Yes, the failures in the automated alert systems have been addressed, so services should be able to disable themselves when a long fork is detected:
https://github.com/bitcoin/bitcoin/pull/2658

[Bit_Happy]

Your .gif was not accurate.
2013 turned out to be a great year for BTC. 

[00ph8al]

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.

Maybe your right? Please point me to a double spend.

What is your definition of double spend?

Are you including operator error and self-inflicted (ie. allowing 0-confirmations)?  The network (and access) isn't always fast enough for every use case either.

[RodeoX]

What is your definition of double spend?

Are you including operator error and self-inflicted (ie. allowing 0-confirmations)?  The network (and access) isn't always fast enough for every use case either.

I think of a double spend as a spend with confirmation followed by another spend of the same balance. Without confirmation it seems to me that the protocol is behaving as designed and, as you mention, it's an operator error. I also don't think that it counts if it happened on the test net.
A true double spend in the wild would spook me. If a method were found to do that, it would be the most serious threat to bitcoin so far.

[Stephen Gornick]

I think of a double spend as a spend with confirmation followed by another spend of the same balance.

Which is what happened in March, 2013.  If you were using the v0.8 client there was a transaction that had more than six confirmations but later the fork which pre-v0.8 clients were mining surpassed the one the v0.8 were using and that transaction became invalid.  What happened was a user noticed the fork, created a new transaction that spent the same funds, used a custom client that repeatedly broadcast the double spend attempt and eventually that new transaction got included in the pre-v0.8 blockchain fork.

So yes, a double spend of a transaction that had six or more confirmations on what was at the time the longest chain is something that has occurred.

The gist of the problem was that miners starting up with the v0.7 client had an empty memory pool and thus no knowledge of the transactions that had already confirmed in the blockchain fork mined by the v0.8 clients.  So then it simply is a race -- whichever transaction (of the two that were spending the same coin) that reached those miners first is the one that was being hashed.   For that specific weakness, there are solutions that had been discussed but not implemented as far as I know.  For instance, when the miner is shut down the unconfirmed transactions in the memory pool could be written to the filesystem and then those transactions get loaded first when the miner starts back up.   That would likely have made the result of that March 2013 fork be that no double spends had occurred.

[stefek99]

This is part of the history!

* https://99bitcoins.com/price-chart-history/
* https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[cointastical]

Five years later, no block explorers still show Macbook-air's original transaction that had gotten double-spent after the block reorg.

Here's a list of seven transactions that (allegedly) had been confirmed on the v0.8 side of the fork, but were later double spent on the v0.7 side of the fork.
 
12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90

Source: https://pastebin.com/raw/wctJU3Ln