Hmm... now if only there was a way to combine a properly written pool implementation that is written in a language that understands performance and multihreading, with a concept that peers together a number of nodes to form a de-centralized network of stand-alone miners large and small.... now that would be something......
Any scalability issues with the python client are not as important as the marginalising problem so that's not really going to help. You can see the problems I described a long time ago as users are now discovering on this thread.
That's why I left p2pool. I was squeezed out. The one share I got rolled off within 36 hours before a block was found (it was one of those long streaks).
I am starting to see what you mean. even 400gh/s is now considered small?! I'm hanging in there but really starting to loose patience with lack of block payouts. What to do?!
Ironically the only current solution I can see is... putting regular pools in front of the distributed pool which of course adds centralisation detracting from the distributed nature, so it's hard to see how this is actually better than just using a full regular pool. I've yet to come up with a better solution to the problem, but that doesn't mean I've given up on looking for solutions entirely.
Well full respect to you Con. What do you think of Bitmains comments on p2pool, what do we expect to see from them? I wish I had the spare cash (and power prices) to go buy a few chunky miners but it's just a hobby for me. Your pool is private atm correct? some of the work you are doing looks great, does it help smaller miners?