At no point was there a double spend in the longest chain

[intel-core-i7]

This is a short summary of a neighbour thread:

Quote from: https://bitcointalk.org/index.php?topic=152363.msg1619287#msg1619287

Whole thread:  https://bitcointalk.org/index.php?topic=152363.0

"this wasn't a double spend - it was a single spend on two different blockchains - I'm not sure why everyone is so concerned about this - the spend only existed once in the longest chain, it just happened that the longest chain changed, and it changed after 6+ confirmations had already happened in a previous longest chain.  The issue here was that the merchant ignored or did not know about the advice to not accept confirmed blocks from the currently longest chain (the 0. because the 0.7 chain was going to outgrow it and invalidate those transactions.

At no point was there a double spend in the longest chain, which is exactly how bitcoin is designed to work.

Will"

So stop the "double spend panic" ... Nothing near a 2-spend happened really.

[lucif]

In any case it is a fuckup for the merchant - no matter call you it double spend or not double spend.

And this $10k fuckup is not caused by merchant, but by network - no matter call you it double spend or not double spend.

[Stephen Gornick]

no matter call you it double spend or not double spend.

I've no idea how that is anything but a double spend.  A merchant received a payment.  That payment got six confirmations from the latest release of the Bitcoin-Qt/bitcoind client that had sync.   Then later that transaction reverted to 0 confirmations and will eventually disappear as if it had never been made.    

The coins that OKPay thought it got have since been sent by the customer somewhere else.

Spend #1 of a coin: to address of OKPay's hosted (shared) EWallet
Spend #2 of same coin: to address under customer's control.

There's no other name for it.  That's the definition of a double spend.

[move_zig]

There's no other name for it.  That's the definition of a double spend.

I think a double spend, in theory, is when you send the same money to two people and neither is reversed. This should be impossible with bitcoin. What happened was a blockchain fork and one of the spends was reversed when the older fork became the "true" fork.

So I agree that this is not a double spend.

[mornaner]

There's no other name for it.  That's the definition of a double spend.

I think a double spend, in theory, is when you send the same money to two people and neither is reversed. This should be impossible with bitcoin. What happened was a blockchain fork and one of the spends was reversed when the older fork became the "true" fork.

So I agree that this is not a double spend.

Say I buy something from you and pay with BTC. The transaction gets six confirmations and then you send me the item I bought. Then, the transaction gets reversed because the fork and I get the BTC back. You lost the item and the Bitcoins and now I'm able to spend them again.

The transaction was reversed, but the merchant lost an item due to a network error, he didn't anything wrong. Call it as you want, but effectivelly it is a double spend.

[Tirapon]

It was a double spend. All forms of double spending involve forking the blockchain.

https://en.bitcoin.it/wiki/Double-spending

[K1773R]

There's no other name for it.  That's the definition of a double spend.

I think a double spend, in theory, is when you send the same money to two people and neither is reversed. This should be impossible with bitcoin. What happened was a blockchain fork and one of the spends was reversed when the older fork became the "true" fork.

So I agree that this is not a double spend.

thats not possible (atleast not on the BTC chain)

[AndyRossy]

It was a double spend, was not merchants fault, is not good.  However you want to phrase it.

[piramida]

Definitely, there is no alerting system that would warn merchant "the blockchain you are currently using is forked", so imagining there are three parallel forks, each one having it's own criteria for accepting transactions, the same coins could be spent with three different recepients.

It is, in the end, same coin spent (meaning sent and accepted) several times. Yes, it was double spend. No, it wasn't all on one chain. But the whole chain operation is hidden from merchants (as it should be), so from their point of view, they got a confirmed operation that could get reversed. Until this is fixed, as in you can somehow automatically confirm that blockchain is not running in a forked mode, I am not sure how large money transfers could be possible.

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.

[DeathAndTaxes]

At no point was there a double spend in the longest chain, which is exactly how bitcoin is designed to work.

All double spends by definition involve two chains (except those involving 0-confirm txs).  A double spend in the same chain is impossible.  Nodes will reject a tx which whose inputs already exist in another tx in the chain.  So your claim is false.

[Tirapon]

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:

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.

[piramida]

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:

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.

[rocks]

It's not clear to me how this happened even with the 2 chains.

For a period of time (~3 hours) there were two competing chains with pre-0.8 nodes viewing one as valid and 0.8 nodes viewing the other as valid.

However at the same time there was only one network of client nodes sharing transactions and they all saw the same transactions propagate through the network. The original transaction that received 6 confirmations on the 0.8 chain was in the network for ~1 hour before receiving these 6 transactions.

The pre-0.8 nodes had more than plenty of time to see and agree on this original transaction, and should have rejected the 2nd spend as a double spend, even if the original spend had not confirmed in the pre-0.8 chain. My understanding is from a pre-0.8 chain point of view, this case had  a 0-confirm transaction that was in the network for some time, so the network should have rejected the 2nd as a double spend even if the original hadn't confirmed yet. This is also why all the other transactions on the 0.8 chain propagated onto the current chain during the reorganization that happened.

If anyone can provide insight here I'd appreciate it.

[Nemesis]

It's not clear to me how this happened even with the 2 chains.

For a period of time (~3 hours) there were two competing chains with pre-0.8 nodes viewing one as valid and 0.8 nodes viewing the other as valid.

However at the same time there was only one network of client nodes sharing transactions and they all saw the same transactions propagate through the network. The original transaction that received 6 confirmations on the 0.8 chain was in the network for ~1 hour before receiving these 6 transactions.

The pre-0.8 nodes had more than plenty of time to see and agree on this original transaction, and should have rejected the 2nd spend as a double spend, even if the original spend had not confirmed in the pre-0.8 chain. My understanding is from a pre-0.8 chain point of view, this case had  a 0-confirm transaction that was in the network for some time, so the network should have rejected the 2nd as a double spend even if the original hadn't confirmed yet. This is also why all the other transactions on the 0.8 chain propagated onto the current chain during the reorganization that happened.

If anyone can provide insight here I'd appreciate it.

You completely misunderstood what happened.

I suggest you to go and read that double spend thread.

Cant help you if you're lazy

[Tirapon]

My understanding is from a pre-0.8 chain point of view, this case had  a 0-confirm transaction that was in the network for some time
If anyone can provide insight here I'd appreciate it.

Yes, that's basically what happened. The problem arose because the 0.8 miners viewed this block as valid, accepted it, and continued the chain from there. This created a fork with two competing parallel chains, until the 0.8 miners reverted to 0.7 and effectively cancelled all transactions on the 0.8 chain after that block.

[Nemesis]

My understanding is from a pre-0.8 chain point of view, this case had  a 0-confirm transaction that was in the network for some time
If anyone can provide insight here I'd appreciate it.

Yes, that's basically what happened. The problem arose because the 0.8 miners viewed this block as valid, accepted it, and continued the chain from there. This created a fork with two competing parallel chains, until the 0.8 miners reverted to 0.7 and effectively cancelled all transactions on the 0.8 chain after that block.

Wrong, the blocks are orphaned but all transactions are not cancelled.

Its more like a merge than a complete chop-off. So major loss are those .8 miners, who got no rewards for mining those orphaned blocks.

[Tirapon]

Okay, so how does the merge work exactly? Do all transactions get accepted apart from double spends, where any conflict on the 0.8 chain get rejected?

[Nemesis]

Okay, so how does the merge work exactly? Do all transactions get accepted apart from double spends, where any conflict on the 0.8 chain get rejected?

Yup

The transactions in .8 blockchains got " BACK TO THE LINE"

They're still being added to new blocks. I dont know if they're all caught up now. Last i heard, due to the blocksize limits, its very slowly.... thanks to SatoshiDice spam...

[Tirapon]

Ah right, that makes sense. So rather than being cancelled they go back into the pool of unconfirmed transactions. From there, any conflict will naturally be resolved, because double spends from 0.8 chain already appear in the 0.7 chain and therefore get rejected. Thanks for the insight.

[Nemesis]

Ah right, that makes sense. So rather than being cancelled they go back into the pool of unconfirmed transactions. From there, any conflict will naturally be resolved, because double spends from 0.8 chain already appear in the 0.7 chain and therefore get rejected. Thanks for the insight.

Yup this is why some ppl got no clue and said that OKAY double spend was merchant's fault... for accepting 0-confimed transaction. Its not OKPAY's fault clearly as it was indeed confirmed. They just had noway to know there is a fork going on.

They hence lost $10k