Pooled/Remote Mining - Open Source - Updated 2010-12-24

[puddinpop]

Due to the small likelihood that an individual CPU miner will find a block in a reasonable amount of time, and the expectation from new users to see results quickly, I have developed a server/client for bitcoin that will allow many individual miners to cooperate on solving blocks.  This will effectively aggregate their hashing speed, allow solving blocks faster than individually possible, and distribute the generated bitcoins weighted by the contributing node's hash rate.  This can also be used by an individual who doesn't want to run the full bitcoin client on a computer, but would still like to generate blocks with it.

Here is a basic overview of how it currently works.  Someone runs bitcoin as a server, with optional connection password, to accept connections from remote clients.  The server creates a unique block per client, keeps it in memory, and sends it to the client to hash.  The client then hashes the block, appends the first byte of the generated hash to a buffer, and creates a metahash of the buffer when it is full and sends it to the server for later verification.  The client increases the nonce of the block after every hash, but does not modify the block timestamp.  The server will periodically send new blocks for the client to hash, either every 2 minutes, or when the client requests a new block because the nonce is close to overflowing.  Every 10 seconds, the server picks a client with the oldest verified metahashes and verifies the last metahash from that client.  The server will also send status updates to every client every 10 seconds.

Currently there are absolutely no built-in negative consequences for a client sending erroneous data, other than being disconnected for sending malformed packets.  The debug log will contain information about misbehaving nodes though.  However, at this early stage in development, it might be bugs causing the issues rather than malicious clients, so this should be taken into consideration.

Some things to consider:

• The generated coins are distributed either based on the contributing client's khash/s divided by all nodes khash/s, or by each clients total hashes contributed divided by all hashes contributed.  This means the generated coins will have precision all the way down to the smallest decimal place bitcoin allows.  Because of rounding issues inherit with floating point operations, the server will accrue all left over fractional coins, which almost always be a single digit number at the smallest decimal position.
• Because of the metahashing and network activity, the miners will not be as fast as miners strictly dedicated to block hashing.
• The generated blocks may hit the maximum block size if enough clients are connected.  I haven't looked into this deeply to see what the limit is, but just know that it could be possible to reach this limit.
• The supplied remote clients are simple proof of concepts.  A client may be created in any language that is capable of handling socket connections and using json, and use any means of generating blocks available to it, such as GPU.
• The bitcoin binary may have issues displaying and/or using coins generated that are less than 0.01 BTC.  I'm assuming they won't display in the client at all.  I haven't thoroughly tested this.
• It is possible that the server will need lots of bandwidth if many clients are connected

bitcoin server command line options

• -remoteserver           Turns on remote server
• -remotebindaddr=x.x.x.x Bind server to specific adapter.  The default is 127.0.0.1.  Note that this will only accept connections from the local computer.
• -remotebindport=xxxxx   Bind server to specific port.  The default is 8335.
• -remotepassword=xxxxx   Set a password to access the server.  The default is a blank password.
• -distributiontype=connected|contributed    Sets method used to distribute bitcoins.  "connected" will distribute coins only to those clients that were connected when the block being solved was created.  The distribution is based on each connected clients calculated hash rate against the total hash rate at the time a new block is created.  "contributed" will accrue all hashes sent to the server for a given address since the last generated block.  A client may freely disconnect and reconnect and will continue accumulating hashes to whatever address the client specified.  The distribution of coins with this method is based on the hashes accrued by each address against the total hashes accured by everyone.  The server will save the values when it shuts down and load them back up on startup.
• -resethashescontributed    Resets the count of hashes contributed from each address.

client command line options

• -server=x.x.x.x        The address of the server to connect to.  The default is 127.0.0.1.
• -port=xxxxx            The port of the server.  The default is 8335.
• -password=xxxxx        The password to use when connecting to the server.  The default is a blank password.
• -address=xxxxxxx       The bitcoin address you want generated coins sent to.  The default is blank.  A blank address will make the client's share of generated coins be kept by the server.
• -threads=x                Start this number of miner threads.  The default value is the number of cores on your processor if using the CPU miner, or 1 if using a GPU miner.

There is one issue I haven't been able to resolve.  The hashing functions seem broken in release builds in Microsoft Visual Studio.  In particular, the midstate buffer contains a bogus midstate when sending to the client.  I have checked for buffer issues, and initialization issues, but I can see none.  Upon placing error checking code and logging AFTER the hashing takes place, the results come out correct.  Removing the checking code causes the issue to reappear and the midstate to be erroneous.  Go figure.  Anyway debug builds do not exhibit this issue.  There probably is a bug somewhere, so maybe someone else can spot it.

Downloads (Updated 2010-12-24)
Pooled Miner Server/Client source based on SVN 205
Windows Binaries

See the following thread for details on connecting the miner to a server run by doublec
Join a pooled bitcoin mining effort

[Anonymous]

I want a botnet army muwahahahah!!


I have a server collecting dust if you want to set this up dave.
Do you still have the irc channel details I sent you?

[puddinpop]

You're awesome too. No share is sent to you is there? Unless you contribute of course haha.

No, there is no code in there to send anything to anyone other than the remote clients and the left over coins from rounding errors to the server operator.

So, how do you determine how much someone is contributing? I assume you send this information, but since it is open source, what prevents them from taking that number and * 10?

It is based on the rate that they send their metahashes back to the server over the previous 60 seconds.  Since the server verifies that the metahashes are correct periodically, you can be reasonably sure that this rate is a good estimate of the client's hash rate.

The default bitcoin client will not show coins less than 0.01, but you should not send coins smaller than that because you will get charged a transaction fee of 0.01. You should round everything off to 0.01.

Since the creator of a block determines the fees it wouldn't make sense to include fees for our own blocks.  The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed.

Code:

const int64 RemoteClientConnection::GetCalculatedKHashRate(const int sec) const
{
    int64 hash=0;
    int64 denom=(sec*1000);
    time_t now=time(0);
    for(std::vector<sentwork>::const_iterator i=m_sentwork.begin(); i!=m_sentwork.end(); i++)
    {
        for(std::vector<metahash>::const_iterator j=(*i).m_metahashes.begin(); j!=(*i).m_metahashes.end(); j++)
        {
            if(difftime(now,(*j).m_senttime)<=sec)
            {
                hash+=BITCOINMINERREMOTE_HASHESPERMETA;
            }
        }
    }
    return hash/denom;
}

Change the last line to: return hash; and I just increased my share of the pie?

That only affects the calculation on the server, and everyone will still end up with the same ratio of their khash over total khash.  All the client can do to affect this calculation is send valid metahashes as fast as possible.  If they send invalid ones they will be detected.  If they send duplicates ones, they are ignored.

[ribuck]

I would have thought that a better way than a metahash to ensure honesty is to get the remote miners to send back genuine hashes at a lower level of difficulty.

Because there is a known relationship between the ease of generating hashes at different levels of difficulty, you could be sure that a remote miner submitting regular hashes at lower levels of difficulty is doing its fair share of work towards finding hashes at the official level of difficulty.

[tcatm]

You could even calculate the clients true hashrate from low-difficulty results.

[puddinpop]

You could even calculate the clients true hashrate from low-difficulty results.

If you did that, the client would then only have to send low difficulty hashes as fast as possible.  There would be no incentive to hash the actual block trying to be solved.  In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve.  There might be other ways to do this, but I think this is the easiest and most convenient.

[tcatm]

If you did that, the client would then only have to send low difficulty hashes as fast as possible.  There would be no incentive to hash the actual block trying to be solved.  In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve.  There might be other ways to do this, but I think this is the easiest and most convenient.

By calculating low-difficulty hashes for a block it will eventually calculate a target difficulty hash. Why shouldn't it submit it? It'll make it win coins.

[puddinpop]

If you did that, the client would then only have to send low difficulty hashes as fast as possible.  There would be no incentive to hash the actual block trying to be solved.  In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve.  There might be other ways to do this, but I think this is the easiest and most convenient.

By calculating low-difficulty hashes for a block it will eventually calculate a target difficulty hash. Why shouldn't it submit it? It'll make it win coins.

I see what you mean now.  Sending hashes for the target block that are a low difficulty.  Well that could work, but I see 2 issues immediately.  The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one.  The calculated hash rate based on this metric would have to be taken from a large sample size.  The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

[tcatm]

I was curious and read the source. Your metahash approach isn't using separate block as I first thought and it's actually pretty similar to my idea. Maybe you can get rid of the array and just sum all previous hashes to save memory. That might work better with GPUs with low memory (2^32 tried metahashes are ~17 Gbytes).

[Gavin Andresen]

I see what you mean now.  Sending hashes for the target block that are a low difficulty.  Well that could work, but I see 2 issues immediately.  The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one.  The calculated hash rate based on this metric would have to be taken from a large sample size.  The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes.  Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely).

[jimbobway]

This is awesome, I hope to become a zombie to a botnet server soon (since I don't think I have the hardware and bandwidth to support a super server).

[ByteCoin]

The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed.

So just to clarify, you're saying that the coins created as a result of block generation can be spent in the transactions included in that same block. Won't the new block be rejected because the coinbase is not matured? See ConnectInputs. The lack of fees if fees are warranted could also be a problem as ConnectInputs checks for that too.

ByteCoin

[Martian]

This is definitely awesome. I wonder if medium businesses would run something like this on their corporate LAN once bitcoin takes off. Assuming it's worth the electricity costs, having company resources earn income while idle could be very attractive.

Of course, businesses tend to have terrible pcs, but quantity has a quality all of its own. ;-)

One thing is slightly worrying though. If, say, there was a very large global pooled mining server with a majority of CPU power, wouldn't it be able to produce double spending blocks?

[puddinpop]

I was curious and read the source. Your metahash approach isn't using separate block as I first thought and it's actually pretty similar to my idea. Maybe you can get rid of the array and just sum all previous hashes to save memory. That might work better with GPUs with low memory (2^32 tried metahashes are ~17 Gbytes).

It's only 1 byte of the resulting hash, so 4GiB for 2^32 hashes, which a modern card can transfer to main memory faster than the hashes can be computed.  Memory on the card wouldn't factor into it anyway as you just send the results back in small blocks.

I see what you mean now.  Sending hashes for the target block that are a low difficulty.  Well that could work, but I see 2 issues immediately.  The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one.  The calculated hash rate based on this metric would have to be taken from a large sample size.  The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes.  Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely).

What's to stop a client from lying?  They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest."  In reality the client is spending the rest of the time trying to generate his own block.  There is absolutely no way to verify that the client is not lying this way.  With the metahash approach, you can verify every individual hash a client has reported solving.  If they are lying, even about 1 of those hashes, you will know because the metahash doesn't match.

The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed.

So just to clarify, you're saying that the coins created as a result of block generation can be spent in the transactions included in that same block. Won't the new block be rejected because the coinbase is not matured? See ConnectInputs. The lack of fees if fees are warranted could also be a problem as ConnectInputs checks for that too.

ByteCoin

The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. 

[ByteCoin]

Your "metahash" method of measuring work, though more accurate than the probablisitic methods of gavinandresen and tcatm, is a major weakness of your method. In order to check a portion of a client's work, you have to duplicate it. This will not scale well to even tens of clients. An attacker submitting bad metahashes to earn coins without really doing the work will just shut down when found out and start a new client on a new IP.
You would have to exclude new clients until a certain proportion of their results have been checked and then it becomes a probability game where the attackers only falsify perhaps an increasing proportion of their results.

More seriously, you exclude clients (and servers) which are not 100% reliable. I know from Mersenne prime testing that some computers occasionally produce bad results. You can run normal software for years without noticing an error rate of one mistake in every 2^40 ops but your metahash would be very sensitive to such errors. This would result in people running genuine clients on slightly imperfect machines getting annoyed. Note that these imperfect machines are fine for normal hash generation or the probablistic hash rate calculation.

You seem to think that the probablistic hash rate measurement schemes are insufficiently accurate. You might wish to do some calculations to convince yourself otherwise. There's already lots of unavoidable unfair randomness in the amount of computation required to produce a new block.

The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

Eh? This happens anyway! How else do you tell if you've got a winning hash?

What's to stop a client from lying?  They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest."

Nothing. But then the inferred hash rate is very low. To clarify - the hash rate is calculated from the quality and/or number of hashes and NOTHING ELSE. The client doesn't say that it's done a certain amount of work - just the hashes matter.

The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. 

Ah. I thought you and I were thinking along the same lines of an elegant payment method that requires no trust and cannot be scammed which is unfortunately forbidden by a fairly inessential and inelegant Bitcoin rule.
You need to go into more detail about how payment works. The solutions I can think of require the client to trust the server and/or can be scammed.

ByteCoin

[puddinpop]

Your "metahash" method of measuring work, though more accurate than the probablisitic methods of gavinandresen and tcatm, is a major weakness of your method. In order to check a portion of a client's work, you have to duplicate it. This will not scale well to even tens of clients. An attacker submitting bad metahashes to earn coins without really doing the work will just shut down when found out and start a new client on a new IP.
You would have to exclude new clients until a certain proportion of their results have been checked and then it becomes a probability game where the attackers only falsify perhaps an increasing proportion of their results.

Obviously you don't compute every single metahash sent by the clients.  You hash them periodically, and when an erroneous one is found, or you have a suspicious client, you check more of them.

More seriously, you exclude clients (and servers) which are not 100% reliable. I know from Mersenne prime testing that some computers occasionally produce bad results. You can run normal software for years without noticing an error rate of one mistake in every 2^40 ops but your metahash would be very sensitive to such errors. This would result in people running genuine clients on slightly imperfect machines getting annoyed. Note that these imperfect machines are fine for normal hash generation or the probablistic hash rate calculation.

Erroneous results would be a factor for any method of client verification.  The solution is to allow a certain amount of error.

You seem to think that the probablistic hash rate measurement schemes are insufficiently accurate. You might wish to do some calculations to convince yourself otherwise. There's already lots of unavoidable unfair randomness in the amount of computation required to produce a new block.

Indeed, there is a lot of randomness involved, causing the block generation rate to vary widely.  Smoothing the client's reported hash rate out would require averaging over an unacceptable long time period.  This unfairly penalizes clients who wish to hash for short periods of time, requires complex calculation logic, and results at best in rough estimates.

The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

Eh? This happens anyway! How else do you tell if you've got a winning hash?

You compare 1 byte of the hash and only if that byte is 0 do you fully check the hash.

What's to stop a client from lying?  They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest."

Nothing. But then the inferred hash rate is very low. To clarify - the hash rate is calculated from the quality and/or number of hashes and NOTHING ELSE. The client doesn't say that it's done a certain amount of work - just the hashes matter.

That's exactly how it is now.

The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. 

Ah. I thought you and I were thinking along the same lines of an elegant payment method that requires no trust and cannot be scammed which is unfortunately forbidden by a fairly inessential and inelegant Bitcoin rule.
You need to go into more detail about how payment works. The solutions I can think of require the client to trust the server and/or can be scammed.

ByteCoin

The server is capable of sending the block with all transactions to the client for verification.  It does not do so now, but the code would not be too difficult to add.  There is actually a comment in the code to add this feature later.  This way the client can verify they will get their share.  If you would like more detail, the code is the best source of detail you can get.

I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes.  Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely).

What's to stop a client from lying?  They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest."  In reality the client is spending the rest of the time trying to generate his own block.  There is absolutely no way to verify that the client is not lying this way.  With the metahash approach, you can verify every individual hash a client has reported solving.  If they are lying, even about 1 of those hashes, you will know because the metahash doesn't match.

Maybe you don't get what he's saying. Let's look at a target hash say 10 characters, the more 0's at the front the better.

A bitcoin block needs 9 zeros to get a 50 coin block.

You ask for their best result every 10 minutes. If they work for 1 minute on an average machine, they give you a result with 2 zeros. If they work for the whole 10 minutes, they give you a result with 4 zeros. All the results that they are looking for, would be based on the current hash, so there is NO wasted work. They just store their best in the client for the current hash, and send it when the server requests it.

Switch back to the way bitcoin works. Difficulty factor of 1398. Someone trying to cheat sends you back a has worth a difficulty of 1. A real client sends you back a difficulty of 7. Someone on a GPU machine sends you back a difficulty of 190.

The better way to do it, would be to request their best POW for each block. You could take the time each block took, the hash that they were able to find (which verify very quickly on the server side) and come up with a formula of what share they would get. The formula may include smoothing out the high peaks and lows.

It may be the most complicated method... but it sounds so far to me, like the most accurate way to get both a relatively honest answer, and have it be relatively hack proof. All the while generating an appropriate potential block.

How do they hack finding the best hash? If they are finding a stronger hash, they very well could be finding an actual block. Nothing is wasted in this scenario.

I understand what this suggestion is, but I don't see it as a reliable method.  It assumes you will generate a specific difficulty at a specific hash rate in a set amount of time.  We all know this doesn't happen.  How do you factor in unlucky clients?  What about the lucky ones?  The best you can do is take an average over an unacceptably long period of time to smooth out the hash rate.  I think this method is too imperfect, and has potential to penalize or over reward clients too easily.  I certainly wouldn't want to be the client penalized because I couldn't generate a good hash in a given amount of time.

[ByteCoin]

You seem to value the accuracy provided by your "metahash" scheme while apparently tolerating a significant amount of fraud in real-use scenarios. I believe that the probablistic schemes advocated by everyone else are sufficiently accurate, quite possibly fraud proof and result in essentially zero server load. If we can agree some plausible real world parameters beforehand and I crank through the maths I believe I can prove that the random errors produced by the probablistic rate measurement are considerably smaller than the distortions caused by inevietable fraud. Would you change your mind if I proved this?

Erroneous results would be a factor for any method of client verification.  The solution is to allow a certain amount of error.

This strikes me as tricky without using lots of bandwidth. Are you saying you do this at the moment or you plan to do it? How does it work?

There remain a couple of issues from your previous posts which I queried but which remain unaddressed.

The second issue is that each miner would now need to check the calculated hash against the target after every hash.  This is another operation the client must perform and it will slow down generation.

This was in response to a suggestion from tatcm for measuring the hash rate by counting low difficulty hashes. You seem to be suggesting that one drawback of tatcm's suggestion is that you need to compare the hash to the target. You imply that your method avoids this comparison and is superior on that basis. You furthermore imply that the comparison operation has a significant computational cost compared to the hash operation.

In order for you not to be wrong you need to show
1) how your method avoids comparing the hash against the target.
2) that the comparison is not of an insignificant cost compared to the hash operation.

I assert that you will be unable to do so and that therefore you should withdraw your "second issue" with tatcm's suggestion.

What's to stop a client from lying?  They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest."

You seem to be under the impression that the rate calculation can be tricked by sending a few presumably low quality hashes which are the result of an insignificant computational effort. I assert that this is not possible. You need to show why you think the client can lie about its computational effort in this fashion.

Please let me know whether you will only be convinced by an explicit numerical demonstration of the superiority of the probablistic hash rate meaurement scheme and also your response to the two outstanding issues from your previous posts which remain unanswered which are outlined above. Also an explanation of how your metahash scheme can efficiently tolerate computational errors would be welcome.

ByteCoin

[ribuck]

One of the most important things about the pooled mining will be participating in trusted groups.

I don't think that trusted groups are needed if the probabalistic scheme is used.

Each client, modified or not, knows the difficulty of the hashes it has produced and can calculate its expected long-term earnings, although of course there will be short-term fluctuations. A dishonest server will get caught out (and quite soon if several of the clients choose to share their statistics). A dishonest client doesn't get more than its real share of the earnings anyway.

[ByteCoin]

I don't think that trusted groups are needed if the probabalistic scheme is used.

Agreed.

{Deleted incorrect stuff about clients cheating. Thanks to ribuck for putting me right.}

Server cheating schemes and their prevention:

The server can say that a lot of of not quite good enough hashes were submitted by clients owned by the server operator. To prevent this, the server must publish all the hashes which were used in the work calculation.

The server can take the proof of work hashes of one or more of the genuine clients and attribute them to a client owned by the server operator. To prevent this the clients sign their hashes with the public key of the address which they want to be credited with their portion of the pot. The hashes and signatures are all published by the server.

The server can omit to publish the signed hashes of a subset of the clients which are not controlled by him and which did not find the winning hash. This enhances his share of the pot. To prevent this, the clients periodically send signed hashes to the server and the server signs a recipt and returns it to the client. The client checks the recipt is valid before continuing work. If the server omits to publish a subset of the signed hashes then the client has proof that the server recieved them and can publish this to discredit the server. If the server signature is invalid then the client stops work and the amount of computation wasted is limited.

I imagine that gavinandresen's "best hash within a time limit" will be a low bandwidth and predictable method of measuring hash speed in this scheme.

Finally, the server can fail to distribute the 50BTC to the clients. To prevent this I thought the cunning idea was to have as the transactions in the new bock include the distribution of the newly minted 50BTC coinbase to the participants. This would have also prevented all the above attacks in one step. The clients would stop working on hashing the block if the block transactions did not divide the proceeds in a fashion the client thought was fair.
I believe standard Bitcoin software rejects blocks attempting to spend coinbase that hasn't matured. If this could be changed to allowing the spend but making those transactions 0/unconfirmed until the coinbase matures then the whole problem goes away and we're all very happy.

If the server gives the clients credit transactions which don't involve the prospectively minted coinbase but instead some other source of money then the clients can just submit those transactions to the network and get the credit before doing all the work thereby defrauding the server. Otherwise the client just has to take the server's word for it that the merkle root they're using includes transactions crediting them appropriately. There's no way of proving it. This is a problem.

There might be a solution involving nifty scripting.

ByteCoin

[ribuck]

The client can cheat if it generates the winning hash in a naive implementation by failing to transmit the winning hash to the server and just transmitting it directly like a normal Bitcoin client and taking the 50BTC for itself.

No, I don't think so.

The block being hashed includes the 50BTC transaction awarded to the generator. So a client must decide (before looking for hashes) whether it is hashing a block that will pay itself, or a block that will pay the server. It can't find a hash first, and then decide who it is for.

So there's no risk of cheating. If the client is looking for hashes that will pay itself, it's not participating in the shared mining and won't have any low-difficulty results to send back to the server either.