Topic: Would This Var Diff Hopping Attack Work? (Read 1041 times)
This is similar to a question people asked months ago where they were wondering if people could mine for a pool, and then when they found a block add it to their own solo miner, and get the full 25BTC. It can't be done, as as D&T said, there is some unique information that is confirmed by a pool as being required.
No each worker gets a unique blockheader. If they had the same blockheader they would be duplicating work. This is important other than preventing cheating. You want to ensure each worker is working on unique work, any duplicated work is going to result in less than expected returns. If worker1 attempts all nonces for a specific blockheader we will call "x" and finds no block solution, then having worker2 attempt to do the same thing will always result in no block solution = 100% wasted work. You could have an infinite number of workers attempt to find a solution for a specific blockheader and they will always fail. You want each attempted hash to be on a unique blockheader.
Makes sense, thanks for the detailed explanation
Does each worker on a pool get the same block header though? Because, assuming this works, you could do it on the same pool with multiple workers, it would just be much easier to detect.
Does each worker on a pool get the same block header though? Because, assuming this works, you could do it on the same pool with multiple workers, it would just be much easier to detect.
A nonce which produces a hash below the required target only does so for a specific and unique block header.
The pool sends partial blockheader to a miner. Miner attemps hashes until it finds a nonce such that when combined with the partial blockheader (work) it is below the required difficulty. That is all you are doing in mining is finding the "magic nonce" but that nonce combined with any other blockheader just produces a random hash.
So pool sends blockheader X to worker 1 (set for 64 difficulty).
Worker 1 finds a nonce such that the hash of that is H(x+n) meets target for >32 difficulty (but not 64+).
The pool sent blockheader Y to worker 2.
If worker 2 returns H(x+n) which is the found nonce & hash that worker 1 found it is nonsense/garbage because the pool will take the found nonce n and combine it not with blockheader X but blockheader Y i.e. H(y+n) which just produces a random worthless hash. The pool simply rejects it.
The same logic that applies to solving a block applies to "solving" a share. When mining you are looking for a nonce such that the H(rest of blockheader + nonce) < target. A share is simply a hash which meets a lower difficulty than what is required to solve a block (i.e. difficult 1, 32, or 64 vs 11 million).
A nonce only solves a unique and specific block header. Change anything in the blockheader and the found nonce produced a totally different hash which isn't going to meet difficulty target.
The pool sends partial blockheader to a miner. Miner attemps hashes until it finds a nonce such that when combined with the partial blockheader (work) it is below the required difficulty. That is all you are doing in mining is finding the "magic nonce" but that nonce combined with any other blockheader just produces a random hash.
So pool sends blockheader X to worker 1 (set for 64 difficulty).
Worker 1 finds a nonce such that the hash of that is H(x+n) meets target for >32 difficulty (but not 64+).
The pool sent blockheader Y to worker 2.
If worker 2 returns H(x+n) which is the found nonce & hash that worker 1 found it is nonsense/garbage because the pool will take the found nonce n and combine it not with blockheader X but blockheader Y i.e. H(y+n) which just produces a random worthless hash. The pool simply rejects it.
The same logic that applies to solving a block applies to "solving" a share. When mining you are looking for a nonce such that the H(rest of blockheader + nonce) < target. A share is simply a hash which meets a lower difficulty than what is required to solve a block (i.e. difficult 1, 32, or 64 vs 11 million).
A nonce only solves a unique and specific block header. Change anything in the blockheader and the found nonce produced a totally different hash which isn't going to meet difficulty target.
Hopefully someone can explain why this wouldn't work, I can't be the first person to think of this.
Say I have an account on two different pools
worker: scrubadub.1 on pool A and
worker: scrubadub.2 on pool B
Let's say I can set the var diff manually on both so I set...
scrubadub.1 to vardiff 64 and
scrubadub.2 to vardiff 32
Now I start mining.
If I get a share above 64 I submit it to worker scrubadub.1. That pool accepts it and also credits me for the expected amount of shares under 64 that I would've also found (and not submitted) depending on the rate of shares that I submit above 64. If we stop here I would get credited for roughly 100% of the shares I find (with a little variance)
But, while I'm still mining if I find a share between 32 and 63 instead of just dropping it I instead submit it to scrubadub.2. That pool accepts it and credits me for that share and the expected number of shares I would've also solved below 32 given the rate that I submit above 32.
At the end of the day I ended up with a much larger credit of shares than I actually solved. Pool A can't see any difference in the way I submit shares, Pool B could if I'm so clear cut about it, but you could get more random in what you submit.
So I guess my question is can I locally generate my own work or am I forced to solve the work from the pools (which would prevent this). Looking at my cgminer output for locally generated work (LW:) it seems quite high, but I'm not sure how many "locally generated work" are required before a share is found.
Thoughts?
Say I have an account on two different pools
worker: scrubadub.1 on pool A and
worker: scrubadub.2 on pool B
Let's say I can set the var diff manually on both so I set...
scrubadub.1 to vardiff 64 and
scrubadub.2 to vardiff 32
Now I start mining.
If I get a share above 64 I submit it to worker scrubadub.1. That pool accepts it and also credits me for the expected amount of shares under 64 that I would've also found (and not submitted) depending on the rate of shares that I submit above 64. If we stop here I would get credited for roughly 100% of the shares I find (with a little variance)
But, while I'm still mining if I find a share between 32 and 63 instead of just dropping it I instead submit it to scrubadub.2. That pool accepts it and credits me for that share and the expected number of shares I would've also solved below 32 given the rate that I submit above 32.
At the end of the day I ended up with a much larger credit of shares than I actually solved. Pool A can't see any difference in the way I submit shares, Pool B could if I'm so clear cut about it, but you could get more random in what you submit.
So I guess my question is can I locally generate my own work or am I forced to solve the work from the pools (which would prevent this). Looking at my cgminer output for locally generated work (LW:) it seems quite high, but I'm not sure how many "locally generated work" are required before a share is found.
Thoughts?
Jump to: