Quote from: Holliday on January 09, 2014, 04:29:27 PM

The largest problem is probably variance. Miners seem to hate variance which is why we have large pools to begin with. That's kind of a chicken and egg problem though.

Remember that increased usage of p2pool will only increase payout variance to most miners, the opposite dynamic to that of joining a large centralised pool.

Quote from: dperfect on January 09, 2014, 04:14:13 PM

It sounds like there may be some interest in bringing p2pool (or a similar concept) closer to the reference Bitcoin implementation (whether that be a change in the protocol, bundling p2pool with the reference client, or simply giving p2pool a stronger online presence in connection with bitcoin.org).

I'd like to try and gauge interest in the various approaches to solving this problem, and perhaps (if it hasn't been done already) formalize some kind of plan of action.

The possible directions I'm seeing are (and these are not mutually exclusive):

More discussion leading to a formal BIP submission with changes to the Bitcoin protocol and reference client. Then, I guess we wait and hope that either the core team can get to accepting and implementing that BIP sooner rather than later (understanding that there are numerous accepted BIPs whose priority seem to be uncertain), or someone else can step up to the challenge... makes we wonder though how many developers outside the core team there really are that have the expertise, familiarity with Bitcoin, and incentive to contribute such a fundamental change in the timeline needed.
More discussion about improvements to p2pool (as the separate piece of software it is now) attempting to address any technical shortcomings of p2pool (scaling, speed, hardware requirements, etc).
More discussion about improving the non-technical issues of p2pool - public awareness, user experience improvements, etc.
Discussing ways to add resources/velocity to the speedy development of one or more of the solutions above (in the form of crowdfunding, offering bounties, raising developer awareness, etc).

To reiterate, if all miners were forced onto p2pool tomorrow, the share difficulty would be pushed up so high that I suspect many lower hashing rigs would quit due to the uncertainty of getting a payout (people with less than > 1TH/s rigs could be mining for months with zero payout, which is a risk they won't tolerate in an environment with rising block difficulty and 24/7 multi-100 watt electricity usage)

My brief tug of war with Tier Nolan should illustrate one important area of improvement to investigate: hardware design. The current generation of hardware comprises many ASIC chips working in a single unit, interfacing with a low cost computing device to run the mining software that schedules and feeds the work to the chips. Some aspect of these current designs makes it necessary to only return the results of work in batches that last ~30 seconds. Forrestv overhauled the share interval and the length of the PPLNS window that p2pool uses just in order to accommodate this type of hardware. When GPUs and FPGAs were the dominant mining devices available, 10 second share interval spread over 24 hours was fine. This was changed to 30 second share interval spread over 72 hours for the typical ASIC.

Can we get ASIC designers to produce chips or PCB layouts that make <10 second share intervals possible once again? The dust is beginning to settle in the ASIC node geometry wars, so they'll need some different direction to go in if they wish to continue to innovate.