Topic: What's to stop this type of cheating when using pools? (Read 1718 times)

Ah ok, didn't think about the blockreward-transaction. Thx for your answer

you correctly mention the transactions, and their order.

however you forgot some other things

1. which transactions pool decided to include. he could have his own rules like eligius has. Also, how exactly would you determine the correct order?

2. you want to replace the wallet public key to receive reward with your own, correct? but that would change the transaction that gives out the reward (yes it's also in the block, along with all the regular transactions, surprised?) and hence the merkle root. you can't submit any results generated for different merkle root than you was given by the pool! pool would ignore them even if they constitute a share for YOUR merkle since it would not even know what merkle root you had in mind, and if it did, it would not know which transactions you had in mind - in fact, the fact that he does not remember giving away your new merkle root is enough for your cunning plan to fail.

Ok the merkle root is coming from hashing the different transactions. What if I hack the client so, that it just connects to a single pool and gets all the transactions just from this single node. So it could be possible to get the same transactions as the pool node. If the same transactions are in the same order on the two clients, they should get the same merkle root. Now the only remaining variable is the timestamp, but their the client could just try out the last x seconds. Now you can try out all the found shares against these parameters, and the correct nonce should also win on the second (mirror) client.

So the question is, if the clients add some random reordering when forwarding transactions or when a new transactions is incoming.

Also if the number of transactions per block is very low, ex. at IXCoin, you can just try all the different transaction orders to find the same merkle root.

the getwork command returns different headers each time you use it (which is easy to verify with stock client). the block data contains a field named extraNonce which is iterated for each getwork so the merkle root changes with each getwork.

also there is a timestamp that may change but idk how often it does.

i don't know however how the server knows which version of block a share is made for, probably stores given out getworks or just finds the one that fits... one can read the sources i guess.

btw try reading the wiki, it has a protocol description i think

about the looping, i think it already does loop from 0 to 2^32.

also since it takes long time for the slow miners to loop through att 2^32 values (in this time the new block might be generated by someone else), there is an option in some miners that allows to ask for new work after a number of seconds, so not all 2^32 values are checked for each block, which I guess does not make much difference... hopefully.

Thanks for the answers

One last question (I hope!!):

If the only part of the header generated locally is the nonce (im assuming the timestamp is irrelevant here), which is any number between 0 and 2^256 - 1, then wouldn't that make it possible that different miners could compute the same (most likely incorrect) header. Surely this would reduce efficiency? Could a pool server divide work up between ranges of the nonce, or even giving out different seeds for the random number generator?

Also, would there be any benefit of changing the nonce part of the mining software to loop from 0 to 2^256 -1 rather than using a random number generator? - this would reduce clock cycles used and so increase hashrate.

Am just brainstorming I guess. I'm a math student, and computational efficiency as well as the cryptography used interests me

mining software - nonce and (in some cases) ntime
pool - everything else

merkle root - hash done from transactions included in blocks. Because coinbase transaction is unique for pool, then merkle root is different for every pool. That's the reason why your attack won't work.

Ok.. easy answer lol

I'm sure I could find this info with google/forum search, but since I've created a useless thread otherwise..

Since the header is made up for the following info:

Version (assume this is constant for all pools? at least most anyway?)
Previous Hash (always constant for a particular block?)
Merkle Root ()
Timestamp (must be generated on the miner client side?)
Bits/Target (constant for each block?)
Nonce (must be iterated over on the miner client side?)

Then which info is determined by the pool server and which info is up to the mining software to generate?

I've put my understanding/guesses in the brackets. I think the whole thing depends on the Merkle root - I guess this is essentially the unique identifier to each pool and is why my described cheat wouldn't work?

No, a solution only fits one header. Each pool will have a different header, so you will need different solutions for each share.

Hi,

Is there any mechanism for pools to not be vulnerable to the following cheat:

- A miner runs intermediate code on the local machine/network which connects to multiple pools, getting work from one/all of them.
- This intermediate code then acts as its own pool for whichever gpu/cpu mining code is running.
- The gpu/cpu miners run as usual, returning possible solutions, as they would if connected directly to the pool.
- The intermediate code collects these possible solutions/shares and sends them to all of the pools it is currently connected to.
- Each of the pools running may accept/reject the share as usual.
- The miner running this intermediate code effectively gets multiple shares on each of the pools he/she is connected to, thus multiplying possible profits.

Is this possible?

I am guessing each pool would have a different current header to hash (eg, different timestep, merkle root, etc), so the possible solution would be rejected from all but the pool the work was originally from.

How many bits of info for the header is the pool responsible for and how much does the mining software generate?

Anyway, couldn't see anyone asking a similar question and I'm curious if this my be a cause for some pools seeing more invalid shares than they would expect.

Sorry if I've completely misunderstood how the pools dish out work