Not sure I want to give out all the secret sauce   Left as an exercise to the reader.

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

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.

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.

Yes, still running with plenty of miners attached.

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

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

How does one calculate that?

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.

I consider the bounty paid.  I donated 2 GAU to davout and bitcoin-central, now that Pecunix GAU is supported there for trading.

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.

A quick status update:

Initial testing seems to show the pool database working correctly.  Shares are being found, and correctly being credited to workers.

Still waiting on that first found block (and associated code), so more test workers are still wanted!

I should have a stats page up in 24-48 hours.  Thanks to everyone participating in this test.

Over the next week or two, I am testing some new mining pool software.  If you can spare a miner for an hour or day or three, testing is greatly appreciated.

Worker registration and basic pool details at http://pool.yyz.us/register.html

This is alpha quality software right now -- still have not found a single block.  Payments are made on a best effort basis; this is brand new software and bugs are guaranteed.  The server will go up and down as software updates are applied, so don't be surprised if you occasionally see connection errors.

Please send bug reports and other feedback to jgarzik@gmail.com.  Thanks!

UPDATE:  After discussion on IRC, I think the change should be to represent "10.0" as a JSON string.

That will successfully (a) avoid JSON implementations' int limitations, while achieving the goal of (b) never use floating point to represent bitcoin amounts.

If there is to be any change, please change to use int64 integers with no decimal points at all.

FWIW, this can also be used in conjunction with TCP_DEFER_ACCEPT socket option, which does not indicate a socket is available to accept(2) until data arrives.

Problem is, "TBC" is your own invention, no matter how many times you repeat it.

+1 agreed

Yes.  I am very surprised that Tor and other VPN solutions do not already employ such obfuscation techniques?

To truly obscure traffic, one must (a) send the same length of data at regular intervals or (b) saturate all available bandwidth with data at all times.  Anything else is vulnerable to statistical analysis.  The "random data at random times" method is not very practical for most modern TCP-like messaging applications; also, "random data" + your app traffic may not equate to random data...

Quite true.

I suppose the P2P network could advertise a 'I require SSL' flag, during the normal course of globally propagating the bitcoin P2P node addresses.

And the bitcoin client could be changed to add an option that prefers SSL P2P nodes on TCP port 443.

Still, ultimately you do not need DPI to simply observe bursts of incoming and outgoing traffic behave (a) like bitcoin P2P and (b) unlike HTTP.  Application fingerprinting by packet sniffers is quite advanced.  A lot of information may be deduced even without access to the unencrypted plaintext.