Topic: At no point was there a double spend in the longest chain (Read 2269 times)

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

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.

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.

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.

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:

Here is your answer:




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.

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.

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?

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

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

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

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?

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.

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.

You completely misunderstood what happened.

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

Cant help you if you're lazy

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.

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.

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:

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.

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.

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