[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[oldbushie]

I wonder if the anomaly from Jan 19 is what partially caused the mass exodus, considering that's when users started dropping off considerably.

[1714269002]

1714269002

[smoothrunnings]

Is anyone having a hard time finding bitcoin blocks?

[Krak]

Is anyone having a hard time finding bitcoin blocks?

Apparently the whole pool is.

[kano]

Some days I get as low as 0 or 1 share, other days (today) I've got 9 shares so far with 6 hours to go ...
Expected is 6 shares a day.

I'm not disagreeing with you. But one thing to remember is the PPLNS window in p2pool is currently 3 days since the move to a 30 second retarget time. So the daily variance in your # of shares is softened, since your payments are tied to the variance in your total # of shares over 3 days instead.

Yeah except that since my 150GH/s is small for p2pool the variance is easily pushing results out the window
28th 3 shares
29th 3 shares
30th 3 shares
31st 3 shares
1st 9 shares

(Edit: yes the 0/1 shares was the 50GH/s for a couple of days)

Rejects 2 shares ... yes better than average

Look here if you are interested.
http://198.245.60.111/Pix/20140102-p2poo.png

Yes that's variance, yes that's expected, and yes the way the pool handles difficulty is screwed (as I've explained before )

When I read the last 5 months of posts the other day I saw some discussions you had on the difficulty and large miners having increased difficulty to reduce the total # of shares they have in the sharechain. Edit: Was back around December. I thought there were 2-3 excellent replies that clarified it all for you, but I guess you didn't accept their explanations?

The issue there is the reason why the difficulty jumps so violently all over the place.
The method used isn't valid.
It uses the bitcoind method of estimating difficulty - which with bitcoind is applied to a set of fixed difficulty data and thus produces the expected result.
With p2pool it's a random set of difficulty data (that changes each share) and thus produces the exceptionally high varying difficulty ... as can be clearly seen.

IMO p2pool has massive variance for small miners and I'd call my 150GH/s here a small miners (which it is)

Yes, if p2pool is dropping 150GH miners like flies that's a serious problem. A single GPU miner somewhere can just not be worried about. When I hear "small miner"  I think someone who has an expected share rate below 1 a day, so at times they will not even be in the share chain and receive no payments. I wouldn't think, myself, that a miner with an average 18 shares on the chain is 'small'.

My share chain shares have been 3, 6, 9, 9, 15
(though it's lower since 2 shares where rejected and I'd have to work out which 2 they were)
I've not reached 18 in 3 days yet ...

(... yes I've not commented about the low block finding ... i.e. low payout ... I've not looked at it closely)

Edit: just got 2 shares in 3 minutes ... 1 rejected

[smoothrunnings]

Some days I get as low as 0 or 1 share, other days (today) I've got 9 shares so far with 6 hours to go ...
Expected is 6 shares a day.

I'm not disagreeing with you. But one thing to remember is the PPLNS window in p2pool is currently 3 days since the move to a 30 second retarget time. So the daily variance in your # of shares is softened, since your payments are tied to the variance in your total # of shares over 3 days instead.

Yeah except that since my 150GH/s is small for p2pool the variance is easily pushing results out the window
28th 3 shares
29th 3 shares
30th 3 shares
31st 3 shares
1st 9 shares

(Edit: yes the 0/1 shares was the 50GH/s for a couple of days)

Rejects 2 shares ... yes better than average

Look here if you are interested.
http://198.245.60.111/Pix/20140102-p2poo.png

Yes that's variance, yes that's expected, and yes the way the pool handles difficulty is screwed (as I've explained before )

When I read the last 5 months of posts the other day I saw some discussions you had on the difficulty and large miners having increased difficulty to reduce the total # of shares they have in the sharechain. Edit: Was back around December. I thought there were 2-3 excellent replies that clarified it all for you, but I guess you didn't accept their explanations?

The issue there is the reason why the difficulty jumps so violently all over the place.
The method used isn't valid.
It uses the bitcoind method of estimating difficulty - which with bitcoind is applied to a set of fixed difficulty data and thus produces the expected result.
With p2pool it's a random set of difficulty data (that changes each share) and thus produces the exceptionally high varying difficulty ... as can be clearly seen.

IMO p2pool has massive variance for small miners and I'd call my 150GH/s here a small miners (which it is)

Yes, if p2pool is dropping 150GH miners like flies that's a serious problem. A single GPU miner somewhere can just not be worried about. When I hear "small miner"  I think someone who has an expected share rate below 1 a day, so at times they will not even be in the share chain and receive no payments. I wouldn't think, myself, that a miner with an average 18 shares on the chain is 'small'.

My share chain shares have been 3, 6, 9, 9, 15
(though it's lower since 2 shares where rejected and I'd have to work out which 2 they were)
I've not reached 18 in 3 days yet ...

(... yes I've not commented about the low block finding ... i.e. low payout ... I've not looked at it closely)

Edit: just got 2 shares in 3 minutes ... 1 rejected

The real issue here is that now that bitcoin network equals to more than the top 500 super computers in the world times 256, that we have reached a level were we are mining faster than there are blocks! So we have run out of bitcoins and will have to wait until the other 20 million become available! LOL

[roy7]

Is there a site someplace with a historical graph of the p2pool share chain difficulty? Google has failed me on this one. I'm curious how much the difficulty on the share chain actually moves around.

(A number of alt coins seem to have having success with the Kimoto Gravity Well difficulty algorithm. I don't know the specifics myself, but it changes difficulty each block like XPM/PPC do.)

Edit: Manually clicking through the share chain I see the minimum difficulty changes each share already. I'm curious what the graph looks like though, since kano mentioned it various highly. So far, the biggest single share difficulty adjustment I can find is about 1% of the prior value.

[freebit13]

I'm losing hope here... we lost 100 users which certainly isn't helping variance.

Perhaps it's the patronizing "tone" some of the users here feel the need to use when others ask questions. Some even call themselves "old timers" with 8 months experience. I know it's made me look elsewhere...

[smoothrunnings]

I'm losing hope here... we lost 100 users which certainly isn't helping variance.

Perhaps it's the patronizing "tone" some of the users here feel the need to use when others ask questions. Some even call themselves "old timers" with 8 months experience. I know it's made me look elsewhere...

The lack of finding work, aka blocks, isn't related to just pool but everyone feels it. Before building and using my own P2Pool server I was using Bitminter who was going through weeks of not finding any work and their overall pool numbers started to dwindle. Now they are back to almost 380TH/s, what we are seeing will pass and another pool will be affected then everyone on that pool or almost everyone will jump ship.

[smooth]

I'm not disagreeing with you. But one thing to remember is the PPLNS window in p2pool is currently 3 days since the move to a 30 second retarget time. So the daily variance in your # of shares is softened, since your payments are tied to the variance in your total # of shares over 3 days instead.

Yeah except that since my 150GH/s is small for p2pool the variance is easily pushing results out the window

No its not.

28th 3 shares
29th 3 shares
30th 3 shares
31st 3 shares
1st 9 shares

Let's look at your three day averages:

30th: 3
31st: 3
1st: 5

That is not exactly massive variance.

If you come up with a longer sequence of days where there are zero-share days the same thing will happen. There will be some small jumps and dips but nothing crazy. You won't have a week of no shares for example.  

If you have 150 GH and that averages 6 shares/day then your three day average will not really move around very much.

[roy7]

The issue there is the reason why the difficulty jumps so violently all over the place.

Since I can't find what I was looking for... I made it myself!

http://vtc-us-east.royalminingco.com/p2pool_share_history/diff_history.png

That image will be updated automatically once per minute, plotting share difficulty vs pool non-stale hash rate. Looking over the share chain by hand I couldn't see the difficulty jumping around all that much, so this will at least give us a clear 24 hour picture once it has been running for a full day.

I assume you aren't confusing the share difficulty to find valid shares with the vardiff difficulty sent to your miner on what work to report back for stat purposes.

Edit: Of course, the target difficulty does increase above the share difficulty for miners who are large enough to be generating over 1.67% of the whole share chain (or if people elect to). But as a smaller miner, that doesn't apply in your case. You just need to find the normal minimum difficulty to get a share into the chain.

[kano]

When I fired up p2pool less than a week ago it was showing diff as high as 870k and as low as 650k in the same day ... the few times I clicked on the page ...
Your graph is showing over 10% in a 2 hour range ...

Anyway, it doesn't matter if the code has a limit of 1% per share ... there's ~120 shares per hour

There's the variance of a high network diff vs a small pool (current diff=15,100TH/s p2pool currently says 134TH i.e. less than 1%)
There's the variance due to a high share diff
There's the variance of the share diff itself (it's very erratic over a short time)

The 3rd one is unnecessary ... and needs to be fixed.

heh I just clicked on my p2pool page again a few minutes later and it says 170TH/s ...

[roy7]

It's possible the pool hash rate was moving around a lot that day though. The share difficulty needs to adjust quickly as the network hash rate changes. Since starting my graph 3 hours ago, the non-stale hash rate has been reported from 89T-139T.

I wonder how much of that is actual changes in the makeup of the pool, and how much is variation in the reporting even with no real change in who is mining.

[kano]

It's possible the pool hash rate was moving around a lot that day though. The share difficulty needs to adjust quickly as the network hash rate changes.
...

Actually, no it doesn't need to adjust quickly.
That simply means it will have the erratic adjustments it is having ... and since the source information itself is erratic - (badly) estimated pool hash rate - it will be even more so ...

[bkminer]

So has the problem from December been fixed with the ban peers commit?  I'm still running outgoing only.

[kano]

... and if you keep your log files (I have them for all time I run p2pool ... which isn't much) you can just grep "Share difficulty"
(of course p2pool truncates them and you lose log info - unless you resolve that)

Heh, in the first day of the recent run when I turned on p2pool (6pm to 12midnight) it went as low as 793467.233915 and as high as 940359.665147

In a somewhat tabular form (my timezone) ...
26th 628549.635965 to 955434.444950 23:21:44
27th 623111.657122 to 1005577.897267 00:20:27
28th 667502.146435 to 908145.054910 11:53:23
29th 600278.575638 to 814628.296267 11:03:18
30th 563518.983970 to 762241.221921 10:02:30
31st 524941.323059 to 765905.483240 15:22:34
01st 468151.837131 to 734301.175462 11:53:23

So yes there clearly is decline over the past week ... but during each day the diff varies a lot!
And yes it's not just falling (the time at the end is when the lowest diff was)

Edit: hmm I was trying to work out from the log when the orphans/dead happen - it seems it doesn't want to let you know ... you just happen to find out a little later when the counter increments in the "Shares:" line
e.g.

Code:

2014-02-02 13:21:22.128994 GOT SHARE! user db3d6334 prev 04e3b80b age 28.13s
...
2014-02-02 13:22:57.976632  Shares: 26 (3 orphan, 0 dead) Stale rate: ~11.5% (4-29%) Efficiency: ~100.3% (80-109%) Current payout: ...
2014-02-02 13:22:57.976694  Pool: 124TH/s Stale rate: 11.8% Expected time to block: 21.1 hours
2014-02-02 13:22:59.397758 New work for worker! Difficulty: 64.000000 Share difficulty: 567565.872050 Total block value: 25.064420 BTC including 282 transactions
2014-02-02 13:22:59.521511 New work for worker! Difficulty: 16.000000 Share difficulty: 567565.872050 Total block value: 25.064420 BTC including 282 transactions
2014-02-02 13:23:00.984396 P2Pool: 17381 shares in chain (17385 verified/17385 total) Peers: 6 (0 incoming)
2014-02-02 13:23:00.984510  Local: 154GH/s in last 10.0 minutes Local dead on arrival: ~9.7% (7-13%) Expected time to share: 4.4 hours
2014-02-02 13:23:00.984556  Shares: 26 (4 orphan, 0 dead) Stale rate: ~15.4% (6-34%) Efficiency: ~95.2% (74-106%) Current payout: ...

(yeah my 4th share so far today was my 2nd orphan share today ...)

[oldbushie]

I'm losing hope here... we lost 100 users which certainly isn't helping variance.

Perhaps it's the patronizing "tone" some of the users here feel the need to use when others ask questions. Some even call themselves "old timers" with 8 months experience. I know it's made me look elsewhere...

The lack of finding work, aka blocks, isn't related to just pool but everyone feels it. Before building and using my own P2Pool server I was using Bitminter who was going through weeks of not finding any work and their overall pool numbers started to dwindle. Now they are back to almost 380TH/s, what we are seeing will pass and another pool will be affected then everyone on that pool or almost everyone will jump ship.

I hope you're right. At least we did have a month or two of great luck, just seems to be going in the exact opposite direction right now. I wonder if people with maxconnections set to 0 may be hampering the pool's effectiveness? I know that was just intended to be a temporary measure until the bug is fixed, which it is now.

So has the problem from December been fixed with the ban peers commit?  I'm still running outgoing only.

Yeah, go ahead and change maxconnections to non-zero, I've had it at 10 for the past week and it's been stable with the latest version of p2pool on git.

[nreal]

From Btc-guild January 24, 2014
"There was a brief (3-4 minute) restart on all servers this afternoon in order to apply a critical patch to all stratum servers. This patch was required before the next difficulty update, which is likely to push the network difficulty beyond the 2.1 billion mark. The original stratum code was written with difficulty barely at the 1-million mark, and was not written to anticipate network difficulty exceeding the maximum size of a 32-bit variable."

Does something simialiar affect to p2pool, are all the versions of the bitcoind, leveldb or what ever depedencies ready for exceeding the maximum size of a 32-bit variable?

[smoothrunnings]

The -fee doesn't seem to be working...since I have added it -fee 50 my server has taken home most of the payout. The recent pay looks like this; server = 0.03817988, my wallet = 0.00722744. It looks like that for all the other payouts too. Looks like something is broken in the code.

[lenny_]

The -fee doesn't seem to be working...since I have added it -fee 50 my server has taken home most of the payout. The recent pay looks like this; server = 0.03817988, my wallet = 0.00722744. It looks like that for all the other payouts too. Looks like something is broken in the code.

You need to find more shares, to it will even out 50/50.

[roy7]

The -fee doesn't seem to be working...since I have added it -fee 50 my server has taken home most of the payout. The recent pay looks like this; server = 0.03817988, my wallet = 0.00722744. It looks like that for all the other payouts too. Looks like something is broken in the code.

Must just be variance. How many shares have you found? Remember, the pool doesn't receive 50% of the payout, it receives randomly over time 50% of the shares. So the number of the shares the fee has in the sharechain can vary quite a bit. There is a literal random() call with the fee % to see who owns each share your node finds.

Hard coding in a fee amount to the sharechain like how donations work would be a really nice feature and easy to add. But not backwards compatible, so it'd have to be one of those things that only kick in once 95% of the network has upgraded. Then the variance is gone for both operator and miner in regards to node fee.