Pools With a Significant Hashrate: A Realistic Double Spend Attack Taking 2 Hr

[DamienBlack]

I doubt Tycho keeps tens of thousands of BTC on his online infrastructure. His pool profits (~3% fee) only amount to ~100 BTC per day. But my counter example was also to illustrate that Deepbit, with its size, is now a valuable target to any attacker out there. The fact a pool owns ~50% of the hashrate is bad not only for Bitcoin, but also because it concentrates risk. My advice to users is to not keep any significant amounts of BTC in their Deepbit account.

Yes, but deepbit mines about 3,600 a day total, all of which has to be available if his users withdraw. I bet at least some uses don't withdraw everyday (although I do). It could easily have 5,000 in it.

[1713543979]

1713543979

[1713543979]

1713543979

[1713543979]

1713543979

[1713543979]

1713543979

[1713543979]

1713543979

[1713543979]

1713543979

[DamienBlack]

It is still a double spend, and it is even more obvious if you spend on the main chain first and then try to reverse it.  Check your debug log.  The node already flags chain reversions and double spends.  Sites that wait for multiple confirmations can (should) be watching.

Yes, but the evil pool would not release the "bad" block chain until the first spend already had 6 confirmations, got sold, and sent to dwolla. Then the new block chain would roll it all back.

[MrJoshua]

Look guys, you are thinking about this all wrong.  Security is about how to protect yourself.  The best way to protect yourself is to find that part of your protection that is most at risk and fix it.  

Arguments such as "why would anyone want to break bitcoin", or "you still only have 50/50 chance of double spending" are meaningless in this debate.  These are not factors to what your weakest vector of attack is.  

This is only a simple example, but what if a state actor wished to see the devaluation of bitcoin?  What would they do?  The easiest thing I can think of is a rubber hose attack against the operators of the top n pools.  Now with control of 75% or more of the hash rate the design of bitcoin IS COMPROMISED.  Creative people *will* figure out what the best way to take advantage of that compromise is.  Double spend, ruin the credibility of bitcoin, buy WMD, whatever is the most value to that actor.  Never argue "why would...", "how" is the only argument and if there is a how you ARE vulnerable in that direction.

POOLS ARE BAD!  They make a system that has demonstrable cryptographic security into a "I don't think that guy is cheating, why would he" security.  FAIL!

STOP USING POOLS, or use one of the systems that make pools safe.  If you argue that pools are safe then you are uninformed, or an NSA/CIA/North Korean/Al Qaeda/mobster shill.

If you truly want bitcoin to succeed, then this is a fundamental issue that should be addressed. Risk factors of bitcoin should be evaluated analytically and solved, not justified.

[DamienBlack]

Look guys, you are thinking about this all wrong.  Security is about how to protect yourself.  The best way to protect yourself is to find that part of your protection that is weakest and fix it.  

Arguments such as "why would anyone want to break bitcoin", or "you still only have 50/50 chance of double spending" are meaningless in this debate.  These are not factors to what your weakest vector of attack is.  

This is only a simple example, but what if state actor wished to see the devaluation of bitcoin?  What would they do?  The easiest thing I can think of is a rubber hose attack against the operators of the top n pools.  Now with control of 75% or more of the hash rate the design of bitcoin IS COMPROMISED.  Creative people *will* figure out what the best way to take advantage of that compromise is.  Double spend, ruin the credibility of bitcoin, buy WMD, whatever is the most value to that actor.  Never argue "why would...", "how" is the only argument and if there is a how you ARE vulnerable in that direction.

POOLS ARE BAD!  They make a system that has demonstrable cryptographic security into a "I don't think that guy is cheating, why would he".  FAIL!

STOP USING POOLS, or use one of the systems that make pools safe.  If you argue that pools are safe then you are uninformed, or an NSA/CIA shill.

If you truly want bitcoin to succeed, then this is a fundamental issue that should be addressed.

I agree with you on many points, but I can't stop using a pool. Statistically, I'm never going to hit a block (assuming continued 30% difficulty increases). A pool is the only way I get paid. As difficulty continues to increase, this will be true for more and more people.

The solution is: fix the way pools work so that this attack doesn't exist. People are working on that.

See this thread for more info:

http://forum.bitcoin.org/index.php?topic=9137.0;topicseen

[BitcoinPorn]

POOLS ARE BAD!  They make a system that has demonstrable cryptographic security into a "I don't think that guy is cheating, why would he".  FAIL!

What is worse is the pool within the pool things going on.  I think people will see there is no benefit for themselves to keep mining in a pool overall.  I mean, I can only understand if you think in short term goals with Bitcoin, and especially if you don't give a crap about the other benefits of this specific digital currency.

[mrb]

No. The probability of outpacing the legitimate chain with exactly 50% of the hashrate is 50%.

[mrb]

No. The probability of outpacing the legitimate chain after N blocks, no matter what N is, is always 50%.

Think about it. You don't need to outpace every single block. Only the last one matters.

[mrb]

Also if you crack the pool server it would be more profitable to rob it and send the bitcoins to yourself.

Be creative: you could double your gains by robbing the pool and performing a double spend on this money!

[bcearl]

I don't think that you have 2 hours before anybody notices. The blocks will be generated at half the speed after you split off. And the miners themselves will see that their blocks are not in the legit chain.

You have to make sure that the miners know the illegitimate blockchain only, that's way harder than getting 50 % of mining power. This is the internet. Everybody connects to anybody.

But even if it worked, it looks like way too costly for the risk. Besides the risk of detection there is the thing that MtGox will know that your address with the 10k BTC has reverted a transaction. They won't take any more coins associated with that address.

[kjj]

It is still a double spend, and it is even more obvious if you spend on the main chain first and then try to reverse it.  Check your debug log.  The node already flags chain reversions and double spends.  Sites that wait for multiple confirmations can (should) be watching.

Yes, but the evil pool would not release the "bad" block chain until the first spend already had 6 confirmations, got sold, and sent to dwolla. Then the new block chain would roll it all back.

In that case:

Step 10: A few minutes later, the legitimate block chain becomes longer than my forked chain, which invalidates the 500 BTC I transferred to TradeHill/Bitcoin7/MtGox. The 500 BTC automatically "reappears" in my original wallet. The exchange is short on BTC and is screwed. An investigation later in the day reveal that Tycho's pool was compromised. Tycho's reputation is ruined. People switch to another pool, which gains 50% of the hashrate. The attacker repeats the same attack on this other pool

This step won't work for two reasons.

First, if the exchange sees your chain as legitimate, you need to assume that every miner also sees it that way.  They will be working on the next block to extend your chain, not the old reverted chain.  Your 500 BTC spend to the exchange will not be overturned on those grounds.

Second, if you manage to somehow time your chain transmission so that it forces a race and gives the other chain a chance to get back on top, if it does take back over, every node on the network will instantly put your 500 BTC spend in their transaction list.  Your recovery attempt will be seen as a double spend.

So, you've spent 2 hours to get an instant transfer into an exchange when you could have just waited an hour.

[mrb]

Then the real network has just as much chance to take it back on the next block. My understanding is you have to maintain the forgery sequentially. Other wise I could just put my commodore 64C to work eventually it will find a solution thru sheer luck and collapse the whole shebang.

Point being no matter how many times you flip a coin the odds are always 50/50 but to see a run you have to multiply the odds so 50 percent of 50 percent. To attack bit coin you actual need a factor more hashing power to increase your odds to the point you can. Why else do you think the 6 confirmations were designed in. If cracking one block is all it took why wait for 6 confirms. The reason is the odds of maintaining your run of blocks goes in the toilet.

You don't have to maintain the forgery sequentially.

You misunderstand the math that explains why this specific number of confirmations was chosen by some exchanges/merchants.

Read the original Bitcoin whitepaper http://bitcoin.org/bitcoin.pdf (section 11). If an attacker possesses 10% of the global hashrate (q = 0.1), in order to reduce the probability of a double spend to less than 0.1%, you should wait for 6 confirmation, ie. force the attacker to fork the chains from 5 blocks behind, that's the z=5 quoted in this section. These are the design parameters that the 6 confirmations are supposed to protect against.

If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.

As a side node, I think there is an approximation error, or rounding error when running the sample code with q = 0.5, because it shows the attacker would have a 100% success rate (it should be 50%).

[mrb]

I don't think that you have 2 hours before anybody notices. The blocks will be generated at half the speed after you split off. And the miners themselves will see that their blocks are not in the legit chain.

No, you won't notice a reduced hashrate that lasts for as little as 2h. I showed in the example that it happens all the time, eg. today. Did you find this suspicious? No. Did anyone else? No.

Also, as pointed out by DamienBlack, no pool miner checks that their blocks are in the legit block chain. No one verifies the 80-byte block header they are hashing.

[DamienBlack]

It is still a double spend, and it is even more obvious if you spend on the main chain first and then try to reverse it.  Check your debug log.  The node already flags chain reversions and double spends.  Sites that wait for multiple confirmations can (should) be watching.

Yes, but the evil pool would not release the "bad" block chain until the first spend already had 6 confirmations, got sold, and sent to dwolla. Then the new block chain would roll it all back.

In that case:

Step 10: A few minutes later, the legitimate block chain becomes longer than my forked chain, which invalidates the 500 BTC I transferred to TradeHill/Bitcoin7/MtGox. The 500 BTC automatically "reappears" in my original wallet. The exchange is short on BTC and is screwed. An investigation later in the day reveal that Tycho's pool was compromised. Tycho's reputation is ruined. People switch to another pool, which gains 50% of the hashrate. The attacker repeats the same attack on this other pool

This step won't work for two reasons.

First, if the exchange sees your chain as legitimate, you need to assume that every miner also sees it that way.  They will be working on the next block to extend your chain, not the old reverted chain.  Your 500 BTC spend to the exchange will not be overturned on those grounds.

Second, if you manage to somehow time your chain transmission so that it forces a race and gives the other chain a chance to get back on top, if it does take back over, every node on the network will instantly put your 500 BTC spend in their transaction list.  Your recovery attempt will be seen as a double spend.

So, you've spent 2 hours to get an instant transfer into an exchange when you could have just waited an hour.

The OP set up his attack wrong. But it is still possible in a slightly different way, and he has since updated the original post to reflect the correct attack. This attack _would_ work, make no mistake. It is possible that the miners would all get together and roll back to the "original" chain, and then you wouldn't have any gains. But this would probably involve a lot of pain and suffering and could take days to get sorted, all the while the bitcoin network would be essentially down. There might be a whole lot of confusion over which transfers are real and which aren't and so on... Most likely, to avoid all of that, we would be forced to continue on the compromised block chain.

And I really doubt anyone would notice in only two hours. Sometimes deepbit doesn't hit a block for a full hour and a half. And their stats are delayed by an hour to prevent pay-per-share manipulation. No one checks the shares they produce to see if they have a block. I don't even know of a mining application that tells you. Two hours is well within the time-frame for an attack. If Tycho doesn't notice, no one will.

But still, I find it unlikely that anyone would be able to pull this off. It is more complex then just robbing the pool, for less gain. I don't feel threatened by the possibility. But let me make it clear, it is a possibility. And the odds are 50%, you don't need 6 consecutive blocks, because you are just holding all your block, waiting to release them later. It they are longer than the other chain, then all clients will accept them. That is a bitcoin rule. The longest blockchain is the "real" blockchain.

[DamienBlack]

If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.

Well, each additional confirmation buys you more time. It would take years (edit, only months, because of earlier difficulty) for someone with 51% to undo a transaction with 1000 confirmations.

[mrb]

If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.

Well, each additional confirmation buys you more time. It would take years for someone with 51% to undo a transaction with 1000 confirmations.

No. Run the math. Run the sample Poisson code provided in the whitepaper. An increasing number of confirmations only protect Bitcoin for q < 0.5.
For q >= 0.5, no amount of confirmations can protect anything.

[DamienBlack]

If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.

Well, each additional confirmation buys you more time. It would take years for someone with 51% to undo a transaction with 1000 confirmations.

No. Run the math. Run the sample Poisson code provided in the whitepaper. An increasing number of confirmation only protects Bitcoin for q < 0.5.
For q >= 0.5, no amount of confirmations can protect anything.

Again, it doesn't protect you, it just buys you time, because the attacker has to start that far back in the chain and build a longer chain. But the attacker will succeed (given enough time).

[mrb]

Again, it doesn't protect you, it just buys you time, because the attacker has to start that far back in the chain and build a longer chain. But the attacker will succeed (given enough time).

But in my attack, the attacker doesn't have to start "far back" in the chain. He starts forking it from the last known legitimate block... (sorry for my multiple edits, this is complicated)

[bcearl]

Please answer to my posting: Your attack still assumes that you can split the internet. That you can dictate what blockchain each miner can see.

[mrb]

Please answer to my posting: Your attack still assumes that you can split the internet. That you can dictate what blockchain each miner can see.

No need to "split the internet". The attacker simply withholds the forked blocks, on the pool's server, that are being solved by the miners. Remember that these miners are not connected to the Bitcoin peer-to-peer network. There is no need to isolate them.

[Raulo]

This whole attack is possible but is not undetectable. The pool miners will know they are not working on the main chain. However, most of the miners will have no idea and the miner programs will not print it automatically.

The hash of the previous block is contained in the getwork data returned to the miners. If the miner program does the getwork to the local copy of the bitcoin daemon, it can compare the hashes and print warning. It happens occasionally though (some accidental chain forks), however if it happens twice in a row (chain fork differs by two blocks), it is very unlikely by accident and very likely by an attack. It does not seem to be very difficult to program into the miners as an option to print warning and better yet to switch to another pool if it is happening. If large enough number of pool miners switched, the attack would be prevented.