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.

[1714930463]

1714930463

[1714930463]

1714930463

[1714930463]

1714930463

[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

[Tirapon]

It still seems to me that the suggestion of adding a mechanism to alert miners and merchants of any branches over a certain size would solve this problem?

[rocks]

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.

Thanks for the reply, but my confusion is why the original transaction that was shared throughout the network and picked up in the 0.8 blocks, was not also at the same time recognized as the first original transaction in the pre-0.8 nodes (even if not inserted into a mined block). This should have prevented the issue.

For example, if I send all the BTC from address a to address b in transaction 1, then wait 5 minutes and try to re-send BTC from address a to address c in transaction 2, the network will reject the 2nd transaction as a double spend even if no blocks have mined yet because the majority of nodes have accepted transaction 1. (There is always a risk that the mined block will insert transaction 2, which is why we wait for confirmations because that creates the official record...)

I was watching the bitcoin-dev channel at the time, and the arguments made to fall back to 0.7 were both chains should have the same transactions and the only losses would be for the miners who lost the block rewards. This was stated several times by multiple people as the consensus was reached, it also matches my understanding of how the network works.

My understanding is this should have been the situation for the pre-0.8 nodes, no block was mined yet, but the pre-0.8 network should have still recognized the 1st transaction.

Nemesis, I have read that thread, numerous other items, and the IRC logs from the event multiple times. The above is a serious question, I guess I can't help you if you don't understand what the question is or can't answer it.

[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.

Thanks for the reply, but my confusion is why the original transaction that was shared throughout the network and picked up in the 0.8 blocks, was not also at the same time recognized as the first original transaction in the pre-0.8 nodes (even if not inserted into a mined block). This should have prevented the issue.

For example, if I send all the BTC from address a to address b in transaction 1, then wait 5 minutes and try to re-send BTC from address a to address c in transaction 2, the network will reject the 2nd transaction as a double spend even if no blocks have mined yet because the majority of nodes have accepted transaction 1. (There is always a risk that the mined block will insert transaction 2, which is why we wait for confirmations because that creates the official record...)

I was watching the bitcoin-dev channel at the time, and the arguments made to fall back to 0.7 were both chains should have the same transactions and the only losses would be for the miners who lost the block rewards. This was stated several times by multiple people as the consensus was reached, it also matches my understanding of how the network works.

My understanding is this should have been the situation for the pre-0.8 nodes, no block was mined yet, but the pre-0.8 network should have still recognized the 1st transaction.

Nemesis, I have read that thread, numerous other items, and the IRC logs from the event multiple times. The above is a serious question, I guess I can't help you if you don't understand what the question is or can't answer it.

Gosh, i gave you a benefit of doubts that you're lazy rather than not capable to understand. Now you say i dont understand your questions?

Yes both chains SHOULD see the first transaction..... but NOT at the same time.

Did you actually read the damn thread and follow the IRC channel?

Here is your question:

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Here is your answer:

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.  It would also appease those that want to do far-future locked transactions, whose transactions cannot, by definition, survive a software update cycle.  At least it would give clients/miners a choice about their locked-tx policy, rather than having it decided for them (drop all tx on restart).

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

gmaxwell and gwillen just enlightened me a little further on #bitcoin-dev. The scenario seems likely to me now especially after I got the info that only about 10% of the miners had been on 0.7 before the split. They probably had the initial TX, but just didn't find a block in time.

These are all from the thread that you said you read.
As far as i concern now, you're an idiot.... not a lazy bump.

[rocks]

Again, these responses do not answer the original question which focuses on a different area, instead of attacking, attacking, attacking, maybe you could try to understand the question.

My question was why didn't the network of decentralized nodes block this double spend attack before it ever even propagated to the miners? There are multiple aspects to bitcoin that prevent double spends and the mined record-keeping blocks are just one of these many aspects. The responses above refer to the behavior of the rebooted miners, whereas I asked about the behavior of the decentralized client nodes.

Here is the sequence of events:

1) Block chain forked, pre-0.8 miners on one chain, 0.8 miners on another.

2) Attacker submitted a transaction to the network. This transaction propagated throughout the network efficiently and was accepted by a large enough number of client nodes, both pre-0.8 nodes and 0.8 nodes.

3) A 0.8 miner confirmed the transaction in a block. Time passed and this block received 6 confirmations. However the pre-0.8 nodes still had accepted the original transaction in their logs, even if that transaction was not confirmed in a pre-0.8 block.

This is the part I don't understand - 4) Attacker submitted a double spend transaction to the network. My understanding is this double spend transaction should have been rejected on both the pre-0.8 and 0.8 branches.
4a) The 0.8 nodes would reject the attack because it was a double spend against a confirmed transaction.
4b) The pre-0.8 nodes would also reject the attack because they already accepted the original transaction. Again this original transaction had over 1 hour to propagate and be received by the network of nodes as the 1st and original transaction.

5) 0.8 miners shutdown, clear logs and reboot as pre-0.8 miners. These miners represent <1% of the total network nodes. They reconnect to the network to receive new transactions. The rebooted miners now should receive the original transaction, because both the pre-0.8 and 0.8 nodes should have rejected the attack already and expelled it from the network, with or without the miners.

The fact that the miners cleared their transaction logs seems like it should be irrelevant. After rebooting the miners connected to the same network that should have already rejected the double spend before it ever reached the rebooted miners, as above

Again the mined confirmation blocks is only one aspect that protects against double spends, there are other aspects to protect bitcoin and it seems these protections should have worked here, but didn't. All I want to know is why.

The only answer that seems possible is if the attacker connected directly to the miners right after they rebooted and submitted the double spend first, this seems statistically unlikely.

[rocks]

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

A shorter way to phase this is:

Who would the restarted miners receive the double spend transaction from? Any network node a restarted miner connected to should have already rejected and expelled the 2nd transaction as a double spend, so even if nodes did not rebroadcast the original transaction, they would have already rejected the double spend and would not have propagated the double spend to a restarted miner.

It seems the only possible scenario is if the attacker connected directly to a restarted miner and submitted the double-spend to the miner first. This is statistically unlikely.

[Nemesis]

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

A shorter way to phase this is:

Who would the restarted miners receive the double spend transaction from? Any network node a restarted miner connected to should have already rejected and expelled the 2nd transaction as a double spend, so even if nodes did not rebroadcast the original transaction, they would have already rejected the double spend and would not have propagated the double spend to a restarted miner.

It seems the only possible scenario is if the attacker connected directly to a restarted miner and submitted the double-spend to the miner first. This is statistically unlikely.

OMG.....just stop...

Go back to my previous comment. Isnt it obvious that the tx was never broadcast to the .7 nodes? the restarted miner now dont see the 2nd TX as double spend.

Its a clearly answered yet you're too thick to understand it.

[Stephen Gornick]

It seems the only possible scenario is if the attacker connected directly to a restarted miner and submitted the double-spend to the miner first. This is statistically unlikely.

The original transaction (to OKPay) had fees of 0.0005 BTC:
 - http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195

The double spend transaction had fees 0.00139906 BTC and was mined by BTC Guild.
 - http://blockchain.info/tx/762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91

The double spend transaction wasn't seen by Blockchain.info until 2013-03-12 08:07:30, which was hours after the chains converged.  It got included in the next block.  But BTC Guild had already mined a dozen blocks on the v0.7 side by then.

I'm wondering if BTC Guild included the double spend transaction because of the higher fees versus following the protocol of rejecting it as invalid (for having an input that was already spent in a previously received transaction).