Just translating p2pool as it exists into C, C++, C#, Objective C, Swift, Java, Perl, Lisp, whatever, is not going to suddenly bring the mining masses here. I know a number of us have listed out the problems previously, and a number of us have had discussions on potential solutions to those problems; however, nobody has been able to successfully crack the nut. Maybe the problem is that we're all trying to solve p2pool's problems while keeping ourselves in the context of the existing structure. Let's try another approach. Forget p2pool even exists.
We as a community want a new pool to be created. Here is a list of high-level bullet points we would want to have in our new pool:
- Decentralized
- Easy to use
- Performant
- Scalable
- Inclusive
Please feel free to add to these points and/or provide more details/solutions.
This is exactly what I'm suggesting JB - a complete re-write. But in order to achieve this I think we should do the donation bounty option from within the current p2pool structure, as it's (I think) an excellent way of raising awareness in the community as well as raising funds, while the amount of work involved in making the changes are minimal & simple.
Nothing happening with this then I presume?
Stagnation is a killer.
I've been continuing to noodle on it.
Was at the MIT BTC expo this past weekend and was able to bring up the issues with some pretty smart folks.
The consensus seemed to lean toward addressing the payment threshold and scheme as the key issue, the rest can be addressed by a rewrite in a language like C++.
The challenge is to come up with a method to accumulate payouts for smaller miners within the pool, in a decentralized and trust-less way, so that they can be paid out at some threshold above what is considered dust.The often proposed solution was to centralize the dust payments and payout from a trusted party. This is essentially what Nasty Pool has done, and its a great service for smaller miners, however the fact that it requires trust would take away a lot of what P2Pool has to offer, and I don't consider it a long term solution.
I'm in touch with a couple of the folks I met, including a dev who has the chops to pull it off (with an attractive bounty), however he is just as stuck as we are until we can come up with a solution for accumulating smaller payouts in a trust-less way...
Damn! I wanted to go to that conference and completely forgot when the day came. Was hoping to meet some like minds and discuss p2pool... Shame I missed out.
Anyway, I have some programming experience and would be interested in assisting with development and fixes where I can. Though I am just as stuck with actually coming up with a solution to these issues. Here are some crazy idea...
What if the share-chain played less of an important role in deciding proof of work? Currently something like 10% of the shares are discarded anyway, and sometimes those discarded shares are even valid bitcoin blocks! While we would need the sharechain to keep track of the historical proof of work for the miners on the pool, we should find a way to have the pools sidechain play less of a critical role in the race to decide
valid work. Right now it functions as a microcosm of the greater bitcoin mining space, the share chain is like the main chain just valid work to the sharechain mostly counts to only the sharechain. That should change. The sharechain should be something on the side and not the main focus. It should be just for maintaining consensus, not deciding miners work.
Instead of what we do now, what if there was a window where valid work/shares could be accepted? This could allow for more than one tip of the chain to exist at a time, but as long as the gap between heights of the multiple chains isn't too large, we can keep consensus. There can be a rule so if the desync between the chains is too large, then less valid shares will reject until total consensus is restored. I am not sure how to actually implement that, and will have to look into the practicality of it... This could help with a higher hashrate miner saturating the share finding rate and wasting their work on just the sidechain.
This will make the issue of cognitive distortion potentially worse (or better), but reduce the amount of dead work from race conditions. There would have to be a system in place where instead of the tip of the chain being the confirmed head, the actual tip would be unknown and the actual head would be several shares behind the tip(s). So after (i.e.) 3 shares the head would be decided, but with multiple potential tips... The tips would exist concurrently, the head would lag beyond and assure total consensus. So you would submit a share, and it wouldn't be considered completely valid until several following [miner] shares confirm it. The work you submitted would be counted from the tips found and then validated at the head.
Then on top of that, (if the POW difficulty is still way too high)... Instead of each payout being decided at time of a block found and accurred valid shares, for smaller miners, would it be possible to store what would be considered dust within the pool itself? If we set it up so each node keeps track of the smaller payouts in a multi sig wallet that is handled by the pool and acts as an escrow, this could allow for a smaller miner to submit work that would be normally be too minimal, and have it incur to a payout that would be more than a dust transaction.
In addition to storing just the dust payouts, since a payout isn't totally decided at the time of last share, the main payouts could be stored within this multi-node/sig wallet in case there isn't clear consensus [within the pool] following the solving of a bitcoin block.
I don't even know if this is all possible,
just some thoughts... please pull them apart.
