Thanks to ribuck for putting me right about client cheating. I have deleted the incorrect section from my post.


Magic! I've just looked at the code and it seems to agree. How did you know this esoteric fact?

In this case the scheme runs as follows:
The server publishes its bitcoin address. Any clients wishing to participate start work hashing a block with the coinbase partly crediting themselves and partly crediting the server - possibly half and half?. After some period of time or after a transaction is received, whichever comes first the clients send their best hash signed by the public key they want credited to the server which calculates their share of the hashing effort using the quality of their hash. The server then publishes all the signed best hashes and a new block to be hashed incorporating all the new received transactions (if any) and the coinbase split among the the clients according to their share of the work. The server possibly takes a cut. The clients verify all the published signed hashes and verify that the coinbase output credits them fairly. A winning client can distribute the winning hash block to the Bitcoin network itself.


The server has to publish the signed hashes and or the new block in a fashion so that everyone can see that everyone else sees the same thing otherwise the following server fraud is possible.
Suppose there are 2 normal clients A and B and one server owned client X. They all hash at the same speed so obviously the coinbase should be split into equal thirds. However the server sends signed hashes and new block targets to A, omitting B's signed hashes and similarly pretends to B that A doesn't exist. No matter who generates the winning hash, X walks off with half the coinbase instead of the third he deserves.

ByteCoin

So... have clients send back their best N hashes (and the average should be N times better).

RE: detecting server cheating:  Over a very long period of time, clients should be able to figure out approximately how many hash/sec the server's network is generating.  So they should be able to detect blatant cheating.  I should've taken statistics in college, seems like it'd be an interesting problem to work out the chances that a server is lying based on how many blocks it has generated over the last week...

Thank you, puddinpop! Someone succeeded to generate a block?

If you publish the information on a web page then if the clients want to check they can get the webpage through a proxy server. You don't know which client is really asking for the information so you can't misrepresent the state on a per-client basis.

This, coupled with my signature and recipt scheme above prevents server cheating.

Suppose the default situation is to send the best hash out of four thousand million.
There's a big difference between  now sending the top 100 hashes out of four thousand million and sending the four thousand million hashes.

I doubt you're seriously objecting to the extra bandwidth used by gavinandresen's proposal.

ByteCoin

I've updated the initial post with the latest binaries and source based on SVN 191.

It's not complicated at all.  Someone sets up a server that is publicly accessible, and everyone else runs the miner client with the -server parameter set to the server's IP address.  If the server operator wants to use a port other than the default, or have a password required for connection, you simply add those parameters as well when you run the client.

I have a server running you can connect to if you want to test it out. You can connect to it using the windows binaries in the original post. See http://www.bluishcoder.co.nz/bitcoin-pool/ for IP address and other details.

Yes each instance of remoteminer only uses one core. The idea (I assume) is to run multiple instances for each core. It will always be a little slower than the normal client due to the communication overhead of talking to the remote server. It should work on guest accounts and the 50BC is split based on the khash contributed to the solution of each connected miner. puddinpop will be able to explain more on this since they wrote the code. I'll try and get a GPU miner connected to up the khash rate soon.

puddinpop, there seems to be a typo in cmake-bitcoinr/CMakeList.txt. The references to 'bitcoind' in TARGET_LINK_LIBRARIES should be 'bitcoinr'.

When I got on at the beginning there was 2 others plus my two at around 2500khash then i later saw 6 at 3500khash and even 10 at 6000khash. Right now its 2 at 800 (only me).