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

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

[1714093999]

1714093999

[1714093999]

1714093999

[1714093999]

1714093999

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