Topic: New mining pool for testing (now closed) - page 2. (Read 20756 times)

Got it, thanks! By the way, what indices have I to create for users, shares and credits tables in the database?

This payout has been made.

This mining pool test has been a smashing success.  Thanks to all who helped out with their CPU/GPU cycles.  Here's a quick briefing.


1. What was being tested?
--------------------------------------------------------------------
I'm working on a suite of bitcoin-related services.  Mining pool capability is a small part of that.  This was a live test of code that will be deployed in production later on.  We found many bugs that a static, in-house test could have never found.  slush was also very generous with advice and cautionary warnings.

To thank the community for the help, the core server source code has been GPL'd and released:  http://yyz.us/bitcoin/poold.py   However, it should be noted that that server is missing several data validations that need to occur (to prevent cheating).



2. What is the current status of the pool?
--------------------------------------------------------------------
Only one block was ever generated by the pool (which IMO is fantastic, given current difficulty, short notice and informal nature of this new pool)

You can get real-time stats at http://pool.yyz.us/stats.cgi

As I consider this a concluded test, I will be shutting down the pool next week -- hopefully enough time to generate another block for the remaining folks who contributed shares.  I have switched my own GPU miners back to slush's pool, though my CPU miners are still pointed at pool.yyz.us.



3. What is the status of the payout -- where my money?
-------------------------------------------------------------------------------------------
We have one block (50 BTC), which was confirmed 87 blocks ago as of this writing.

Based on a technical reading of slush's site, I wrote the software so that only miners who got shares in the block we generated got credit:  "When the pool mints a block, only users who worked on that block are rewarded, and only for work they did on that block."  But apparently I wrote the software incorrectly, because people expected to be rewarded based on shares contributed to all blocks up to and including the newly minted 50BTC block.

So according to my software, this is the winning distribution based on those who worked on block 105839,
     mine319.pit00     211
     mine300pit04     48
     BitCoinPurse     7
     worker102     2
     immaminer     2
     Raulo     2
     wtf     2
     test     1
     mine319.pit00     1

That excludes shares contributed on blocks prior to 105839, and some ~18 hours of shares in the current round, and those records cannot easily be recreated due to since-fixed software bugs.

So, since it's only 50 BTC and I don't want to argue endlessly about it, as a compromise I am going send 1.00 BTC to each of 41 registered users, and then divide the remaining 9 BTC up according to the distribution above.

If the mining pool mints another 50 BTC block in the next ~5 days or so, those share records are present, and I can do a real, slush-like distribution of the reward.  After that, the pool server will be shut down.



4.  What comes next?
---------------------------------------------
Here are some tantalizing hints:

• push-based mining (current RPC miners poll for new work every few seconds)
• geographically distributed mining servers in the US, Eur and Asia, for best possible latency
• additional share rewards -- sometimes we might want to compensate you above the 50 BTC reward itself, because your mining increases the security and value of our network

My miner has been connected for a few days so should have some shares in that block. It's slow so it wouldn't have been a large %. Do you have a minimum BTC level threshold before you send coins out?

slush is right, but he's being terse because we discussed the vulnerabilities in private...  Once my further changes survive testing on this new mining pool, I'll update the code again.

Do you care to explain that statement? It resembles a baseless accusation. 

It would be nice to say to potential users that this version is vulnerable and may not be used in production.

This is GPL'd: http://yyz.us/bitcoin/poold.py

Though it's not necessarily exactly what I'm running on the pool at any given time, as I'm constantly tweaking and fixing the server.

I would very much be interested in this!
I'm trying to setup a mining pool for me and my friends who've I've converted to bitcoin!

Where does one get started on writing a pooled server? Considering coding in any language is allready known. (c/c++ are preferred)

^_^

Yes, still running with plenty of miners attached.

Still running?
 i get a problem communicating with bitcoin RPC
Just changed the address, port, user and pass from the script I use to pool with slush

The pool found its first block last night, block # 105839.

Now that a block is in the database, work on statistics may commence.

I have added 1 thread on a 2.6GHz i7 -- about 1k hash/second.

Running much more smoothly today...

shares * 2**32 / round time

How does one calculate that?

What is the current hash/s value?

The pool server was upgraded to a more robust multi-threaded model, which I'm hoping solves some of the timeout issues reported.

Email (or post here) any questions or issues.  Still searching for that first block, so the payout code has not yet been exercised.  If you can spare some GPU/CPU power for testing this pool, it is appreciated.

Right now the pool is around 9 getwork/second.

Stats are definitely on the todo list.

Any chances of an open source pool?

The pool will probably see many restarts in the first 24-48 hours of its lifetime.

Additionally, I am currently using python's BaseHTTPServer, which seems to sometimes pause for several seconds before giving up on a socket, and processing more.  As soon as this is turned into a multi-threaded server, that should not be a problem anymore.