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

[theymos]

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.

I think it's possible to create a coinbase transaction with one generation input and several outputs.

[ByteCoin]

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

I think it's possible to create a coinbase transaction with one generation input and several outputs.

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

[puddinpop]

The original post has been updated with the latest source.

I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic.  Averaging over 10 minutes doesn't reduce the error to an acceptable level.  Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state.

I think a dual approach would work best.  Use the metahash for accurate hash rate and complete verifiability of hashes reported by a suspicious client, and use the best hash to quickly check a client's work.  This will allow both scalability of verification and accuracy of the hash rate.

I've also added the full block to the message sent to the client when sending work for the client to do.  This way the client can verify the block has an output to their address.

Also, I've added the ability to ban clients by adding them to a file named banned.txt.

As far as verifying that the server isn't lying, I don't think that's possible with a multi client, single server architecture.  The server can lie about anything to any client, and each client will be none the wiser.  The only way around that is if each client has perfect knowledge of the other clients connected to the server.  One way to do this is setting up something similar to a torrent tracker, where the server and each client register with the tracker, and the clients can use the tracker to verify the work they are doing and verify the server is also accurately reporting the work other clients are doing.

[Gavin Andresen]

I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic.  Averaging over 10 minutes doesn't reduce the error to an acceptable level.  Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state.

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...

[puddinpop]

Toss up a couple of windows binaries and I'll host a server if anyone would like to join to test it out.

The first post has been updated with binaries.  Because of the issue I was having with the hash generation, I had to turn optimizations off for the bitcoin and bitcoind binaries.

I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic.  Averaging over 10 minutes doesn't reduce the error to an acceptable level.  Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state.

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

Now you're getting closer to just sending every hash the client generates.  I thought the argument was against that.

[LZ]

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

[doublec]

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

So far there are eight clients connected to my server. No blocks generated yet but I'll be interested to see what happens when a block does finally get generated.

[ByteCoin]

As far as verifying that the server isn't lying, I don't think that's possible with a multi client, single server architecture.  The server can lie about anything to any client, and each client will be none the wiser.

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.

Now you're getting closer to just sending every hash the client generates.  I thought the argument was against that.

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

[doublec]

Is there any way for the server to see about how many k/hashs the pool is generating combined?

It would be nice if the standard 'getinfo' returned the combined k/hashs in some way. The clients seem to get the information. It periodically prints it to the console.

[puddinpop]

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

[bober182]

I'm down for joining this any one got a good tutorial to set this up on a windows PC.

[puddinpop]

I'm down for joining this any one got a good tutorial to set this up on a windows PC.

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.

[bober182]

What is the IP?
I just really hope no one from the forums decides to start making teams and starts splitting up generation that would ruin the point of this.

[doublec]

What is the IP?
I just really hope no one from the forums decides to start making teams and starts splitting up generation that would ruin the point of this.

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.

[bober182]

Okay got it running
OS Vista Fully patched
Ram 2.5GB
CPU Intel Centrino 2 Dual Core Duo

Normally I get 800~1200 khash/s
but with this I get around 300,333,366,400,433 I'm assuming thats the weird way it shows speed.
I noticed that it uses one core only can this be fixed.
So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client.

Will this work on guest accounts then I could run it at school.
Also how is the 50 BC split now.

[doublec]

Okay got it running noticed that it uses one core only can this be fixed.
So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client.

Will this work on guest accounts then I could run it at school.
Also how is the 50 BC split now.

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.

[bober182]

You guys say its split based on the rate. Will this not mean if I have connect and disconnect a lot with my super mega fast client I get more then a non stop small guy. It should be done by the amount of hashes you computed to the amount it too to solve the block.

[doublec]

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

[puddinpop]

Okay got it running
OS Vista Fully patched
Ram 2.5GB
CPU Intel Centrino 2 Dual Core Duo

Normally I get 800~1200 khash/s
but with this I get around 300,333,366,400,433 I'm assuming thats the weird way it shows speed.
I noticed that it uses one core only can this be fixed.
So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client.

The calculated hash rate is averaged over a period of time, so it will start off low and increase until it approaches the actual hash rate.  There is overhead in calculating the metahash, finding the best hash, and networking, so you won't get the hash rate you get with the vanilla bitcoin client.

Will this work on guest accounts then I could run it at school.

As long as you can run random executables, have the firewall allow the traffic, and have the Visual C++ 2005 Runtime files installed it will work, but I don't suggest you run this anywhere you don't have permission to.

Also how is the 50 BC split now.

It's based on the proportion of the contributing node's calculated hash rate to the total hash rate of all nodes.  If you contribute 1000 khash/s and all other nodes contribute 4000 khash/s, you get 1/5 of the 50 BTC.

You guys say its split based on the rate. Will this not mean if I have connect and disconnect a lot with my super mega fast client I get more then a non stop small guy. It should be done by the amount of hashes you computed to the amount it too to solve the block.

The distribution of payment is determined by which clients are connected at the time the block is created.  If you connect and disconnect multiple times, only the last active connection will be valid.  In addition, because of the averaging of hash rate over a period of time, the client will start off with a low calculated hash rate after each connection.

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

Yes there is.  All the bitcoind in that file should be bitcoinr.

[bober182]

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).