Amen, brother!  So many threads calling this pool out.  So many posts proving time and again that the business model couldn't possibly work.  Such absurd commentary by some incredibly vocal idiots trying to skew facts and convince people into believing the BS.  Anybody who ignored the facts has nobody but themselves to blame.  You reap what you sow.

You've gone and proven my point.  Statistics, as kano has clearly shown, provide all the evidence needed to understand that it is absolutely expected that at some point in time this pool, and every other pool, will encounter 500%, 600%, 700%, etc.  That absolutely in no way means there is something wrong with the pool.

By the way, looks like the pool found a block a few hours ago.

Another lucky winner .  Wonder how long he was renting until the block was found...

Thankfully MRR protects you as the rig owner in these cases.  I've had people rent my rigs and fail to setup proper pools, or to setup backups, resulting in them getting no hash rate.  They can blame you all they want, but they won't get any coin refunded for things that are their fault.  Meanwhile, your gear fails over to your own backup pool and mines for you during the contract.  Any time I see this occur on my rigs, I always contact the renter to inform them that something is wrong on their end.

Not sure how betarigs handles this scenario, but MRR has done a great job of it for me.

Wrong.  

First, you might want to understand how Bitcoin actually works.  Then, you might want to figure out how many coins are generated when a block is found -- hint it's not 50.

Even IF what you're claiming were true, then this isn't a bitcoin generator, it's a bitcoin stealer.

About time somebody brought this thread back to the magic beans and Nigerian princes.

That's not an entirely true statement.  P2Pool was the first pool to merge mine it - around February of last year - (all you have to do on a p2pool node is add a parameter to the start script).  F2pool would have had to write custom code in their pool to accomplish the same kind of thing (using auxpow) to merge mine HUC.

Anyway, f2pool has been doing it for a while, so it's definitely not a "recent" thing .

Exactly.  I was asking him to investigate what he's got going on with his bitcoin daemon since the relay client doesn't connect to issue RPC commands over 8332, it connects as a peer over 8333.  I was also letting him know that merge mining coins on p2pool doesn't impact his bitcoin daemon.  It impacts his miners, and the pool is constantly sending restarts (resulting in higher discarded/rejected work) as new blocks are found on those alt coins.

In other words, changing the rpcthreads parameter should have no impact on the relay client.  Now, if he's solo mining and has 100 miners pointed to that bitcoin daemon, each making requests to create blocks, then he'd want to increase the rpcthreads parameter.

Seeing all of those disconnects, I'd suggest looking at the maxconnections.  Default is 125.  If he's running up against that number, then the relay client connection could be rejected by the node.  Then again, my node runs at 125 connections and the relay network doesn't suffer the disconnection problem he's reporting.

Certainly nothing stopping you from creating a little app to do just that for yourself.  As -ck mentioned, the output is raw JSON, and there are plenty of libraries out there available to play with JSON objects.  You can then format the data from it to your heart's content

Merge mining other coins has no impact on your bitcoind.  The impact it has is on your miners... the more coins you are merge mining, the more restarts your miners are subjected to.  You aren't connecting to port 127.0.0.1 - that's an IP address.  You are connecting to that IP address on multiple different ports (each coin has its own... for example, Bitcoin's RPC port is 8332).  What do you have running that could be consuming the RPC connections?  That's what you need to investigate.  P2Pool is certainly one... anything else?

I'm always amazed at how biased people's understanding truly is.  A pool goes for a week without finding a block and things must be wrong with the pool itself.  Yet, when the pool finds many more blocks than it should, nobody's yelling that something is wrong with the pool.

And then p2pool goes and finds two blocks more.  That's a nice feeling as well .

Yes it is .  You take a look at your front end and say, "Well, that sucks, we haven't found a block in a while." Then take a look at your wallet and see a new mined transaction and say, "Oh... somebody's orphaned/dead share found a block!"

That's a little misleading... the payments arrive immediately when the block is found.  They are generated coins, so they show as "Immature" in your wallet.  You must wait the 101 confirmations before you can spend them.

The bitcoind I have running my p2pool node doesn't even have the wallet functionality compiled in to it.  It's purpose is to process transactions and create blocks .  I point p2pool to another address as p3yot33at3r described earlier.  In either case, that address exists because p2pool needs to know who to pay any fees to, and also who to pay if a miner is mining on your node with an invalid BTC address.

Pretty sure if I had 20PH of hardware, I'd be solo mining.  That's nearly 8 blocks expected a day.  Why would I chase luck on some other pool?  I agree with -ck's assessment of their mental acuity .

There are a number of front ends available...

hardcpp's - https://github.com/hardcpp/P2PoolExtendedFrontEnd
johndoe75's - https://github.com/johndoe75/p2pool-node-status
justino's - https://github.com/justino/p2pool-ui-punchy

Installation is pretty much the same for them all - replace the contents of your web-static folder with it.  In case you want to keep your original (again, commands are *nix based):

Well... since the Earth's computations were completely screwed up when the Golgafrinchans arrived, the question became "What do you get when you multiply six by nine?"... but you don't find this out until the end of the Restaurant at the End of the Universe.

Of course, when Deep Thought first told the answer to the pan-dimensional beings after 7.5 million years of calculations, the receivers of the answer decided to form their own question.  They went through a few options like, "How many Vogons does it take to change a lightbulb?" and "What's yellow and dangerous?"  Ultimately they ended up going with "How many roads must a man walk down?"

So far yes.  I've compiled and built quite a few from source on both Ubuntu and OS X.  This was the only one that I've had to change anything for Ubuntu.  I also built UNO and HUC from source today without any edits.

Yes.  You will need to stop the currently running p2pool instance, and then start a new one (the python command) for whatever OS you're using.  I posted the Linux/OS X commands.  Somebody who runs a Windows install could give you the proper syntax for that OS.

You start p2pool like this:


That will give forrestv a 2% donation and will charge anyone who mines on your node a 1% fee.

I found my problem.  I had to edit the following files:

util.h
bignum.h
main.h
db.h
db.cpp

with the following:

Later versions of glibc change the way things are done (including macro definitions).  Including the standard C definitions cleared up the problem.