Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 207. (Read 2591920 times)

You can not lower the minimum alt share requirement.  You can only raise it.

M

No.

You can only lower your share difficulty to the network's determined difficulty.  You do this by using the "/" after your address.  This may sound confusing, but it's pretty easy in reality.

If the node you're mining on has a considerably higher hash rate than what you are contributing, then it is advantageous to you to tell the node you want to have the network minimum share value.  For example.  Let's say that I run my own node and I have 30TH/s on it.  If you bring a single S5 onto my node, then you should setup your user name like this: "MYBTCADDRESS/1000".  That "/1000" will ensure that the node will accept the minimum share difficulty for your miner - which right now is 3,200,000ish.  My 30TH/s miner, if I set the user name up like this: "MYBTCADDRESS", will assign me a share difficulty of about 14,000,000.

P2Pool assigns your miners difficulty based upon the node's total hash rate.  You override that value by using "/".

Hope that helps.

Yes it's been discussed (and done) many times before. You'll see the irony in this solution when you realise that the solution to the problem with distributed mining is... pooled mining. It requires a level of communication and trust and coordination which totally undoes the whole concept of everyone running their own p2pool node which need not have any trust component to it.

Isn't it true that if you mine on a node with other people (in your local area, to keep latency down), you can reduce difficulty to get a share that way (as the entire node finds a share, and distributes it to the participants via a lower difficulty pps method)?

I see that to be a viable workaround to flaw #2 above. Sure, it might boost centralization a bit as miners conglomerate into local nodes, but as long as there are geographic distances between miners super-nodes (51% of hashrate) shouldn't exist due to latency.

If this has already been answered in the thread, sorry! 

Let me be clear - stratum is not the issue here, it is just a communication protocol for the actual mining and it is NOT stratum or p2pool's stratum implementation that is the problem.

You need to get a firm grasp of what is involved in mining, pooled mining and the p2pool share chain first before you can understand where the problems are.

Let that not stop you from starting on the bits you do understand though since you have to start somewhere when helping out with an established project you're new to.

I would say the three main problems are:

1 - it's single threaded.  that means it starts to bog down, FAST, with heavy loads.
2 - share chain difficulty is directly proportional to pool hashpower.  the more hashpower there is, the higher the share chain difficulty, making it harder and harder for smaller miners to get a share.
3 - 30 second work restart.  this directly relates to #2.  p2pool targets to get a share on the alt chain once every 30 seconds.  the more hashpower, the quicker shares are found, so the higher the share chain requirement.  weak hardware (which is most of it) does not like 30 second restarts.  some hardware tolerates it, but suffers (bitmain hardware with up to date firmware).  some hardware is okay (spondoolies).  some hardware doesn't work at all.  increasing the time frame for a share means higher share difficulty.  see #2.

I think #2 and #3 are the fatal flaws of the current p2pool design.  Those have to change radically for p2pool to be successful on a wide scale.

When trying to solve #2 and #3 remember p2pool is decentralized.  each share submitted to the alt chain is a potential block, and contains the payout information for all miners who've successfully submitted shares on the alt chain.  furthermore, each p2pool node verifies the work submitted to the block chain.

M

EDIT: Most hardware today is designed with the BTC protocol in mind, which means complete work restarts every 10 minutes.  That's 20x less frequent than p2pool.  Most conventional pools (At least those I've watched the data flow through closely) submit new work every few minutes or less (without a work restart requirement), but they continue to accept old work until the miner can switch to the new jobs.  p2pool doesn't do that.  every 30 seconds (on average), it's a hard restart, and old work is ignored.

Can you summarize (or link to one?) as to what the current problems are? I'm relatively new to p2pool and haven't had a chance to catch up on all 600+ pages of this thread yet. Thanks

No, but it's an issue nonetheless. A bounty might hopefully get the ball rolling.

Development isn't the current issue.
You need a workable design that overcomes the current problems first ...

More of this please!!!! I will throw some btc at development as well.

Count me in for a bounty. We can't just let p2pool die.

Spun up a node yesterday and pointed some gear at it

You're right on the point where cosmetic start-up issue is not the biggest problem. Starting from there, could you list known fundamental problem?

To my knowledge, stratum don't keep its socket open(am I wrong?), thus scalability shouldn't be much of an issue here if the computer is fast enough. This could be profiled to get a better idea.

Incidentally, I too would have no problem contributing to a bounty fund for a rewrite if anyone suitable/capable can be found. I fear that if nothing is done, p2pools days are numbered.

The stratum protocol bits are just string manipulation but that part alone is only one tiny component of writing pool software. It was good enough in the days when only one client was expected to connect to a p2pool instance, but if you want p2pool to be useful it needs to attract big miners to push the hashrate which means hundreds if not thousands of clients for a local p2pool instance. It does not remotely scale. There are far more fundamental problems that need addressing in the modern world of mining than the mostly cosmetic startup exception issue.

Stratehm/stratum-proxy works just perfect on p2pool, not sure why but even one s4 hosted at umisoo works just fine without any changes to queue.
Best results ever   worth to try, and it supports nicehash too so when the price is right...

https://github.com/Stratehm/stratum-proxy

I already knew that    but I have been spreading mine around as well.  I am on Kano's, Slush and have moved some to BAN to check on payments. I have rented miners for p2pool and will move miners from the PPS pool to p2pool as I want to keep shares.

 

Nice one bud.

I've spread it out over a few pools, as I hate centralization & hopefully it will help keep variance down. Any pool that pays on time, isn't plagued by shills & is run by a reputable & trustworthy dev is good by me.

So no, not BAN 

i think it's only the 0.10 bitcoin core installation that it reduces the mining powa on P2pool, actually ... 
for me, it's 2 days without the bitcoin core -from 0.9.1 to 0.10-