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

[doublec]

@davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10.

What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved.

I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves.

[1714053457]

1714053457

[FreeMoney]

@davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10.

What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved.

I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves.

Even GPU generators are beginning to be exposed to some high variance and that will only grow.

[bober182]

But in theory assuming the current difficulty does not rise.
50 bitcoins are generated per block for now. If your going at 1000khash and it takes 1 month to get the coins this sucks.
Meanwhile, someone going at 4000khash will make 4 blocks before you make one. So 5 blocks have been made in one month and you have 50 bitcoins and your GPU nemesis has 200 bitcoins. If you use correct pooling that measures not speed at generation but how many hashes generated. After one week you may not find the winning hash but GPU will. You get 10 bitcoin he gets the other 40. After the month has ended and you and him generate 5 blocks together. You will still have 50 bitcoins and he will have his 200.
All this does is divide the way bitcoins are generated to a quicker approach. A weak machine will only get its fair 50 after the time it would normally take to generate a coin. If every last bitcoin user joined in on a network bitcoins would tick in at a and even rate still giving GPU and server farms more coins then the rest but allowing CPU users to get a bit of coins before they die.
I truly hope there wont be a competition with the pooled mining teams and that the server doesn't start taking fees.

[da2ce7]

My GPU mining computer melted... (stupid Aussie summer heat)... One I have it back running (1 week approx) I'll volunteer to join for debugging.

[bober182]

Can someone edit the first post to include the server IP so we can all join in this.
Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs?

[doublec]

Can someone edit the first post to include the server IP so we can all join in this.
Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs?

I'm fine with keeping it running. It runs on a VPS which isn't doing much else. I'll be monitoring the CPU usage and bandwidth but it looks like it doesn't use much.

[doublec]

My GPU mining computer melted... (stupid Aussie summer heat)... One I have it back running (1 week approx) I'll volunteer to join for debugging.

Unfortunately it seems there's no GPU enabled remote miner client. What is your GPU setup? CUDA or OpenCL? Windows, Linux or Mac?

[doublec]

If you want people to connect to you, create a new thread stating such, in the main post give your IP address, and link the binaries and a simple how to.

Keep it up-to-date if new releases come out.

I started a webpage with details: http://www.bluishcoder.co.nz/bitcoin-pool/

I'll start a thread once I've got the GPU situation and/or some linux binaries sorted.
Actually probably better just to  a thread. Thread here: http://bitcointalk.org/index.php?topic=2027.0

[puddinpop]

I've updated the first post with the newest source and binaries.

The main changes are

• Decreased bandwidth utilization, especially for incoming bandwidth to the server.  This will only take effect is both server and client are running this new version.  If there is a mismatch between client and server version, the bandwidth usage will actually be slightly increased.
• More details displayed by the CPU miner, including the number of blocks generated by the server since it was started, and how many coins the client will get if the current block is solved.  Please note that the first block sent by the server to the client won't have any coins being distributed to the client because it has effectively 0 hash/s at that time.

[doublec]

I've updated the first post with the newest source and binaries.

Thanks, I've updated the my pool server to use this. I like the extra information the remote client shows!

[doublec]

Some changes I had to make to the latest source to get building on Linux:

1. I had to add the following lines to the end of cmake-bitcoinr/CMakeLists.txt

IF(NOT WIN32)
   TARGET_LINK_LIBRARIES(bitcoinr pthread)
ENDIF(NOT WIN32)

It needed pthread to link on Linux. I made it 'NOT WIN32' in case it's needed on Mac too.

2. In src/remote/remotebitcoinheaders.h, removed the "../blah.h" includes and replaced them all with a single:

#include "../headers.h"

This got things included in the right order. Not sure if that's the optimal fix.

[bober182]

BUG
If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out.

[puddinpop]

BUG
If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out.

That's not a bug, that is how it was designed to work, and you're not losing anything, as no blocks were generated while you were connected.  You need to be connected and actively contributing to get a share of the coins.  Now I am currently working on an alternate distribution method that would count all hashes sent to the server since the last solved block, and distribute based on that.  The server operator will have to select which distribution method they want to use.

[bober182]

Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work.

[puddinpop]

Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work.

I'm at a loss to understand why you think sending a deluge of valid hashes near the end of block generation, or any other time for that matter, would somehow result in a flawed implementation.  The hashes are either valid or not.  It doesn't matter how many are sent, or when they are sent.  They are either valid and counted, or not valid and discarded.

[bober182]

Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should.

[BitLex]

and why do you expect the pool to get "the next" block?
it's not only you and the pool on the network, there's others creating blocks all the time and you might get nothing for a very long time.

not sure if i like the count-all-hashes-idea,
it kinda erases the lottery-style of bitcoin.

[puddinpop]

Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should.

If a client disconnects who was generating a large amount of hashes, and the block was subsequently solved, then he wasn't involved in the creation of the block at all.  It doesn't matter if he provided 99.99% of all hashes up to that point if none of those hashes generated a block.  One and only one client generates the block.  You value total hashes contributed more than hash rate at a point in time, but others may not value this distribution method as much as the current method.  Some may think one method is more fair than the other.  Both methods will be available in the next release, and the server operator will need to decide what to use.

not sure if i like the count-all-hashes-idea,
it kinda erases the lottery-style of bitcoin.

Well, as you can see, some people like the "count all hashes contributed" approach, and some prefer the "connected client hash rate" method.  I'm in the process of uploading a new version which includes the new method.

[puddinpop]

I've updated the first post with the latest release.  This includes a backwards incompatible change.  Clients and servers both need to run either the old version or this version.  Otherwise the clients will hammer the server with connections, only to be disconnected over and over.  I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time.

[doublec]

I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time.

I will most likely be doing this after the weekend sometime. I'll post a more exact date/time later.

I've been requested to set up a git repository with changes specific to getting the remote miner compiled on linux. I've done this and it's at: https://github.com/doublec/bitcoin-pool

The 'master' branch should build the remote miner only on linux by running cmake followed by make. The 'bitcoin-remote-20101201' branch contains the source originally from puddinpop for that version with no changes. You can get a diff to see my (minor) changes to get things to build by diffing these two branches.