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.