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

[DamienBlack]

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.

[DamienBlack]

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.

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

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.

[DamienBlack]

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.

[bcearl]

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.

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

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.

[Raulo]

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.

[MrJoshua]

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

[bcearl]

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.

[mrb]

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

[DamienBlack]

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]

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.

That's correct, and what I said from the beginning: the whole attack can be performed in 2h.

[bcearl]

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.

That's correct, and what I said from the beginning: the whole attack can be performed in 2h.

6 blocks in a row that require twice the time are not statistically insignificant.

[mrb]

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.

The hash of the "previous block" in the getwork reply is actually completely opaque data to a pool miner, who cannot verifies whether it is legitimate or not. One reason being that it varies based on unpredictable data that is known by no one else but the pool owner (eg. the 50 BTC generation fee transaction).

The only way to prevent the pool vulnerability I described is, as pointed out by DamienBlack, a significant rework of the getwork & pool interface: http://forum.bitcoin.org/index.php?topic=9137.0

[mrb]

6 blocks in a row that require twice the time are not statistically insignificant.

Yes it is. It happens many times every single week. Check the timestamps on blockexplorer.com. Also:

The only visible effect is that the global network appears to solve ~6 blocks (instead of ~12) during these 2 hours; but no one notices because it happens all the time due to expected statistical variation. As a matter of fact, it is happening right now: in the last ~110 minutes only 6 blocks have been solved (135104-135109), and there is no reason to find this suspicious whatsoever.

[bcearl]

6 blocks in a row that require twice the time are not statistically insignificant.

Yes it is. It happens many times every single week. Check the timestamps on blockexplorer.com

6 times in a row? Show me a single example!

The whole point of the 6-blocks-makes-a-confirmation rule is that the probability falls exponentially, and that with 6 blocks in a row it is practically impossible to happen.

[mrb]

I already gave it to you. Multiple times. "In the last ~110 minutes only 6 blocks have been solved (135104-135109)"

[Raulo]

The hash of the "previous block" in the getwork reply is actually completely opaque data to a pool miner, who cannot verifies whether it is legitimate or not. One reason being that it varies based on unpredictable data that is known by no one else but the pool owner (eg. the 50 BTC generation fee transaction).

Getwork returns data (essentially block header) and midstate. Midstate can be created from data. Data contains block header which MUST contain previous block hash. Block header contains also merkle root which is unpredictable but everything else must be consistent.

Hash is unpredictable but the data to be hashed must be valid. Otherwise the block will not be accepted by the network.

[bcearl]

I already gave it to you. Multiple times. "In the last ~110 minutes only 6 blocks have been solved (135104-135109)"

You are right, sorry. At least the average meets your requirement.

[bcearl]

Block header contains also merkle root which is unpredictable but everything else must be consistent.

You could ignore that, you don't have to accept transactions anyway.