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

Looked over Windpath's site, looks cool. I remember the Node Stats was the front end I liked and used on my pools. I see my blocklines pull request did get merged in. mmouse and iongchun had made some nice tweaks as well. iongchun added a link on the default page addresses to an address-specific page, where all stats were based just for yourself. Quite nice and personal for a no-login stat system.

I eventually turned my own little miners off (just an S1 and a couple tiny things) so I don't have the hash power to even bother with alt coins any more. The hassle of IRS reporting when they released their guidelines is what was the nail in the coffin for me.

Working on it.......

Thank you sir, may I have another?

Good job! 

Awesome!

Yeah, I'll keep a few here, as long as the hash rate stays low........

Glad you decided to point them here, then

Holy smoke - seems it was one of my old S3's that found that last block!

Outstanding 

Welcome back... haven't seen you for a while .  You're right, not a whole lot has changed.  There's still excitement when we find blocks, disappointment when we don't and the rest of the time is spent discussing the same topics: variance and its effect on miners, how to address the problem of variance with "small" miners, if anyone has a solution to the scaling problem...

Pool hash rate has gone up to 4PH/s and down as low as 800TH/s.  Share difficulty has run the gamut as well.  Windpath has done some really nice work and his site has become the de-facto goto for p2pool-related stats.

Haha. No worries.

Yeah that was a typo by me
Should have read:
/diff is irrelevant for fake (pseudo) shares when used by small miners
(but that should be an obvious typo from what else I said)

---

The issue is small miners, so the changes don't help.

The fake pseudo shares are controlled by +DIFF. The actual difficulty of shares you are trying to submit for credit (not just graphs/hashrate purposes) is /DIFF. Agreed that he's possibly too small for it to matter. (I have no idea what p2pool's share difficulty or bitcoin's difficulty are these days.) /DIFF is usually used by huge miners to reduce their shares/block by voluntarily targeting a very high difficulty target. Small miners running their own node don't need to worry about it, the vardiff logic won't push their target too high.

It's only a problem if you are a small fish in a large public node. In raw p2pool a year ago (no idea if the code has changed), the share-chain diff target for miners on a node was based on the node's hash rate (not the miner). Thus small miners on a public node also being used by other much larger miners would have diff targets higher than the share-chain minimum difficulty. By using /DIFF you can override that. If you want to make sure you always mine at the minimum possible share-chain difficulty, you could just use /1 since it'll make the share-chain difficulty the floor.

Relevant code includes my attempt to fold this into official tree:

https://github.com/forrestv/p2pool/pull/174

And iongchun's branch where he provides some config options to give you more manual control over how it works, but with the same intent/basic result. However, this only effects psuedo-shares.

https://github.com/iongchun/p2pool/tree/auto-worker-diff

Here is me trying to get iongchun's stuff merged in as well:

https://github.com/forrestv/p2pool/pull/187

TLDR: Public node operators should use both 174 and 187 to help small miners be served appropriate difficulty target automatically.

Unfortunately that wont help him in any way (unless he was a big time miner)
/diff is relevant for fake (pseudo) shares when used by small miners
The p2pool share-chain diff is what you must meet before you get a share that will be paid.

I don't know if you are running your own node or what, and this is my first time in ~8 months looking in the forum, but have you tried /DIFF if you want more frequent (but smaller value) shares? It won't do anything if you are already submitting at the network minimum diff level. But if you are on a public p2pool node that isn't running my old patches, your share difficulty might be higher than it needs to be. (I have no idea if any of my work ever made it into p2pool itself or not.)

Some info:

https://bitcointalksearch.org/topic/m.6556442

I'd suggest running your own p2pool node is the best choice, secondly running off a public node running my patches unless someone else or forrest did something better which made them obsolete, or thirdly manually adjusting /DIFF.

I've not been active in the bitcoin community for a long time now, just randomly popped in the thread to see what's up, and I see this is still a topic of conversation. It's important to note (as you did) it is simply perception/variance, and people don't actually lose any income. If you can only find 1 share every 2 blocks, that share will pay enough that the income per block is still the correct average. This was a common point of confusion and misinformation a year ago. I suspect it will persist forever.

Somehow http://p2pools.com wasn't registered?? It is now   Got a very basic setup going testing out the p2pools. Adding a new coin everyday or so, the ones running have already been tested for days and haven't had any issues.

solid 2,5PH/s ... new farm launch for monday tested on sunday ? 

True but if you can just hold your gut in you realize it's variance. Sure he could miss a good run, but it's exactly as likely that he will have triple the number of shares when the next single block is found (thus evening it out).

p2pool's problem is that there are two dimensions of luck (shares and finding a block) but really over the long term it is exactly the same luck as say Eclipse or whatever. Now the perception is your's screwed if you are a small miner, but that's only looking at the short term.

A feel-good fix would be cool and might reduce small miner variance, but isn't that what operators like nastyguy do? Provide a place to mine and get more steady payouts while still on the p2pool concept?

Also in order to do p2pool right you have to run the stupid blockchain and a p2pool python thing. That's another problem: The dumb-ass blockchain node needs to be kept up to date and fast otherwise you will lose out with a high stale count. Blah.

I guess I'm confused by what point you're trying to make.  If you're trying to compare shares found to hash rate, the only noticeable spike in your hash rate graph happens for a couple hour period.  There is plenty of other time where the hash rate is relatively constant that you're not finding shares.

We all recognize that as the pool's hash rate goes up, so to does the difficulty of getting a share onto the chain, which statistically means you find fewer.  However, it also statistically means the pool itself finds blocks more often.  Let's say you've got your 6.9TH/s and the share difficulty is 6.5M.  Statistically you expect to find a share about every 1.1 hours or so.  Assuming each red spike represents one share, you found 9 shares in 12 hours, so you're a bit lower than expectations.  Also, you can clearly see the distribution of found shares is nowhere near the "one an hour" expectations, but rather is clumped together.

Remember last year (August) when share difficulty topped 10M for the first time?  Remember when it topped 20M a few times shortly thereafter?  That's what squeezes the smaller miners out.  Seeing a statistic that says it'll take you a day or more to find a share... and then hoping your share actually gets accepted and not orphaned.  Basically, as long as your expected time to share is less than the pool's expected time to block you're OK.  When it starts taking you longer to find a share than it does for the pool to find a block you perceive your mining to be "wasted" because blocks will be found for which you receive no payment.

This is exactly what I've been saying for months now - p2pool just can't scale properly with the increased hash rate, the more the hash rate - the worse the problem. I only point a few old S3's at p2pool now, & then only when the hash is below 2PH - any more than that & it's wasted.

It's such a shame, really