Topic: Pools With a Significant Hashrate: A Realistic Double Spend Attack Taking 2 Hr (Read 11743 times)
July 07, 2011, 11:42:24 AM
Exponential difficulty could kill this type of attack. And it would take a lot less coding effort than changing every node, pool, proxy and miner.
July 07, 2011, 10:45:25 AM
Quote
(07:54:46 AM) cacheson: cuddlefish: hey, remember that solution you proposed a while back to prevent 50%+ attacks by pools? is anyone still working on that?
(08:03:54 AM) cuddlefish: cacheson: I might
(08:04:07 AM) cuddlefish: cacheson: don't know much about mining
(08:05:36 AM) cacheson: cuddlefish: I'm talking about this thread: http://forum.bitcoin.org/index.php?topic=9137.0
(08:05:53 AM) cacheson: cuddlefish: no replies for a month, was just wondering if there was anyone still working on it
(08:06:13 AM) cacheson: cuddlefish: seems particularly relevant right now
(08:06:18 AM) cuddlefish: cacheson: I won't code it
(08:06:23 AM) cuddlefish: but please do
(08:06:24 AM) cuddlefish: please
(08:06:28 AM) cuddlefish: i'd use your pool
(08:06:33 AM) cacheson: cuddlefish: :/
(08:06:34 AM) cuddlefish: with my CPU netbook miner
(08:07:18 AM) cacheson: cuddlefish: I don't know any more than you do about the gritty details of mining than you do. less, considering that you came up with the idea. but anyway, I'll take that as a "no, no one is working on it"
(08:07:46 AM) cacheson: cuddlefish: er... mangled that message, but you get what i mean
(08:12:32 AM) cuddlefish: cacheson: k
(08:03:54 AM) cuddlefish: cacheson: I might
(08:04:07 AM) cuddlefish: cacheson: don't know much about mining
(08:05:36 AM) cacheson: cuddlefish: I'm talking about this thread: http://forum.bitcoin.org/index.php?topic=9137.0
(08:05:53 AM) cacheson: cuddlefish: no replies for a month, was just wondering if there was anyone still working on it
(08:06:13 AM) cacheson: cuddlefish: seems particularly relevant right now
(08:06:18 AM) cuddlefish: cacheson: I won't code it
(08:06:23 AM) cuddlefish: but please do
(08:06:24 AM) cuddlefish: please
(08:06:28 AM) cuddlefish: i'd use your pool
(08:06:33 AM) cacheson: cuddlefish: :/
(08:06:34 AM) cuddlefish: with my CPU netbook miner
(08:07:18 AM) cacheson: cuddlefish: I don't know any more than you do about the gritty details of mining than you do. less, considering that you came up with the idea. but anyway, I'll take that as a "no, no one is working on it"
(08:07:46 AM) cacheson: cuddlefish: er... mangled that message, but you get what i mean
(08:12:32 AM) cuddlefish: cacheson: k
July 07, 2011, 10:19:47 AM
Who, exactly, is working on this?
July 07, 2011, 08:11:21 AM
Which hacker with such skills will really ruin the entire economy for a few thousand bucks?
I would say the same ones who hacked into MtGox, cracked so many strong passwords that no one has a clue how they did it, crashed the market to $0.01/BTC, and ended up stealing a miserable 2000 BTC.
July 07, 2011, 06:49:43 AM
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).
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).
That thread hasn't been touched in the past month. Who, exactly, is working on this?
The fact that this shit is still going on, combined with the ridiculously pollyannaish mentality of most bitcoin users, is seriously alarming.
Maybe the best way is to create a open source mining software solution that is good enough to be adapted by mining pools.
Everything else is doomed to fail, nobody can enforce mining pools to take care about security.
July 07, 2011, 06:01:41 AM
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).
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).
That thread hasn't been touched in the past month. Who, exactly, is working on this?
The fact that this shit is still going on, combined with the ridiculously pollyannaish mentality of most bitcoin users, is seriously alarming.
July 07, 2011, 05:17:24 AM
Personally, I would urge exchange owners to require 144 or 288 confirmations (nominally 24 or 48 hours).
It is definitely too draconian. Imagine there is a sudden jump in BTC value and you want to cash out. Sorry, 24 hour waiting.
The exchanges can, however, instate a 24 hours waiting period for cashing out. Essentially, you could withdraw balance that was there 24 hours ago. If there is a BTC reversal, the perpetrator would have a negative BTC balance in the exchange account. The USD balance that is hold for 24 hours could cover the loss then.
July 07, 2011, 04:42:31 AM
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.
Hash is unpredictable but the data to be hashed must be valid. Otherwise the block will not be accepted by the network.
Right. In theory it should be possible to modify miners to check this previous hash. For some reason I only remembered the merkle root was here.
July 07, 2011, 03:59:23 AM
It is being worked on by smart people.
Couldn't help but grab that one. Thank god for smart people! ;p
Yes, if it were in my hands... heaven help us.
July 07, 2011, 03:58:13 AM
It is being worked on by smart people.
Couldn't help but grab that one. Thank god for smart people! ;p
July 07, 2011, 03:50:53 AM
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).
Yes I know thank you. Let's hope the entire bitcoin enterprise isn't compromised in the next six months.
I love playing with risk like this. It's like smoking, the best possible outcome is nothing at all, worst outcome you die a painful death. It's not like you win billions of dollars for the risk you take on, nope just nothing or death. In some universes that's a game not worth playing, apparently not so much here.
j
July 07, 2011, 03:46:25 AM
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.
July 07, 2011, 03:44:29 AM
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.
July 07, 2011, 03:41:57 AM
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.
July 07, 2011, 03:40:30 AM
I already gave it to you. Multiple times. "In the last ~110 minutes only 6 blocks have been solved (135104-135109)"
July 07, 2011, 03:34:49 AM
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.
July 07, 2011, 03:32:25 AM
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.
July 07, 2011, 03:28:31 AM
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.
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
July 07, 2011, 03:24:45 AM
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.
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.
July 07, 2011, 03:18:39 AM
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.
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.
Jump to: