Pages:
Author

Topic: Pools With a Significant Hashrate: A Realistic Double Spend Attack Taking 2 Hr - page 2. (Read 11743 times)

jr. member
Activity: 56
Merit: 1
Then the problem is insecure pool design.

I'm sorry.  Have I somehow missed what this entire thread is about?

Pools reduce the security of bitcoin.  End of line.

j

Yes, but listen. IT IS FIXABLE. And smart minds are working on it. It is only the current manifestation of the pool system that allow these pool attacks to work.

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

It is possible to have pools work with zero pool attack risk. It is being worked on by smart people. The new system will probably be adopted soon (within 6 months).
mrb
legendary
Activity: 1512
Merit: 1028
Well in that case, the attack would have to be ongoing for as much time as the number of confirmations. In the two hour attack, you can go undo 6 confirmations, in a two month attack, you could undo 600 confirmations (or whatever). Confirmations is still linked to time somehow.

Right. Got you.

Personally, I would urge exchange owners to require 144 or 288 confirmations (nominally 24 or 48 hours).
full member
Activity: 168
Merit: 103
Then the problem is insecure pool design.

I'm sorry.  Have I somehow missed what this entire thread is about?

Pools reduce the security of bitcoin.  End of line.

j

Of course they do. That's trivial. But you cannot enforce that people don't do pools. So you have to discuss how pools could be more secure.



EDIT: Btw. deepbit gets huge at the moment. Cheesy

member
Activity: 76
Merit: 12
Then the problem is insecure pool design.

I'm sorry.  Have I somehow missed what this entire thread is about?

Pools reduce the security of bitcoin.  End of line.

j
full member
Activity: 238
Merit: 100
When you are in a pool, you only get pre-hashed data. You can't see anything you are working on.

OK, I have not used pools for a long time but if they return a valid getwork (and they should), then getwork returns the block header. The hash of the previous block is there.
https://en.bitcoin.it/wiki/Block_hashing_algorithm

Pools only need to manipulate the target hash so the miners submit all the hashes of difficult 1 and above
The attacker may try to spoof the data block, but then the hash of the data would differ from the midstate.
full member
Activity: 168
Merit: 103
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 block, on Tycho'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.

But you have to distribute the block in the whole mining pool to generate the next one.

No you don't. The pool pre-hashes all the data. The pool miners have no idea what they are working on, nor do they need to generate it themselves.

Then the problem is insecure pool design.
full member
Activity: 168
Merit: 103
Another detail is that with the half mining power you only get 3 blocks per hour because of the difficulty.
So you need 2 hours in the first place to get a confirmation that MtGox accepts.
jr. member
Activity: 56
Merit: 1
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 block, on Tycho'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.

But you have to distribute the block in the whole mining pool to generate the next one.

No you don't. The pool pre-hashes all the data. The pool miners have no idea what they are working on, nor do they need to generate it themselves.
full member
Activity: 168
Merit: 103
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 block, on Tycho'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.

But you have to distribute the block in the whole mining pool to generate the next one.
jr. member
Activity: 56
Merit: 1
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.
 

When you are in a pool, you only get pre-hashed data. You can't see anything you are working on. This is the main problem with pools.
jr. member
Activity: 56
Merit: 1
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)

Well in that case, the attack would have to be ongoing for as much time as the number of confirmations. In the two hour attack, you can go undo 6 confirmations, in a two month attack, you could undo 600 confirmations (or whatever). Confirmations is still linked to time somehow.

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.

All the clients use the longest rule-following blockchain. If you can provide a longer one then the current one, everyone will use it.
full member
Activity: 238
Merit: 100
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.
 
mrb
legendary
Activity: 1512
Merit: 1028
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.
full member
Activity: 168
Merit: 103
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
legendary
Activity: 1512
Merit: 1028
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)
jr. member
Activity: 56
Merit: 1

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
legendary
Activity: 1512
Merit: 1028

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.
jr. member
Activity: 56
Merit: 1

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.
jr. member
Activity: 56
Merit: 1
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 Smiley

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.
mrb
legendary
Activity: 1512
Merit: 1028
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.
Pages:
Jump to: