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

[-ck]

not quite true, u can even use BFL FPGA's with p2pool if you use cgminer in combination with --bfl-range

--bfl-range does not work with singles, but only with minirigs, if I remember correctly.

spiccioli

Minirigs only, yes, and the first generation MRs didn't even support it.

On the other hand, it will be totally irrelevant with ASIC hardware since it hashes so fast there is no need to cut work up into smaller chunks.

[1713561546]

1713561546

[1713561546]

1713561546

[1713561546]

1713561546

[1713561546]

1713561546

[twmz]

Any way to get a more in-depth statistical analysis automated enough to host it somewhere like p2pool.info?

It's possible to automate it. Don't know if p2Pool.info could host it though.

If someone else wants to develop it, I would be happy to host it on p2pool.info.

The easiest way to incorporate it into p2pool.info would be for it to be entirely client side (running in the browser, i.e. written in javascript).  Maybe using something like D3.js to draw the graphs.  As a reminder (it's posted somewhere else in this thread but hard to find), all of the data that p2pool.info has about blocks and round lengths, etc, are available in JSON from here:

http://p2pool.info/blocks?all=true

If someone does this, feel free to message me and I'll help get it on the site.  Or if someone wants to develop this and host it elsewhere, I'm also happy to link to it from p2pool.info so that people will find it more easily.  Just let me know what you prefer.

[Aseras]

twmz, is there any way you could make the tabs ( active users, current payouts ) work on a iphone/ipad?

[twmz]

twmz, is there any way you could make the tabs ( active users, current payouts ) work on a iphone/ipad?

They work fine on my iPhone.  What problem are you having?

[organofcorti]

Any way to get a more in-depth statistical analysis automated enough to host it somewhere like p2pool.info?

It's possible to automate it. Don't know if p2Pool.info could host it though.

If someone else wants to develop it, I would be happy to host it on p2pool.info.

The easiest way to incorporate it into p2pool.info would be for it to be entirely client side (running in the browser, i.e. written in javascript).  Maybe using something like D3.js to draw the graphs.  As a reminder (it's posted somewhere else in this thread but hard to find), all of the data that p2pool.info has about blocks and round lengths, etc, are available in JSON from here:

http://p2pool.info/blocks?all=true

If someone does this, feel free to message me and I'll help get it on the site.  Or if someone wants to develop this and host it elsewhere, I'm also happy to link to it from p2pool.info so that people will find it more easily.  Just let me know what you prefer.

I only have experience in R and a little python. If someone wants to set something like this up I can write scripts in R to provide data or static graphs, or else explain what data you need and how to calculate it.

I still think that the charts on p2Pool are great - much better than available at most pools. Maybe that's the problem - so much data that miners interpret the data in a way that it wasn't meant to be used.

"Luck" graphs are good at helping miners reconcile what they've earned with what they should have earned, but shouldn't be used to look for problems with the pool. There's no automated way to analyse the data for problems without generating many different analyses and teaching miners to understand them. It's not a simple task.

[Subo1977]

ok. I do not mean to complain, however, but it will be found to get worse with the times around a block. but everyone says it's normal and no one is strange. I Think the L* change in correlation with  the p2pool versions. but everyone says that it is all normal :-) .

Wath's going on People?
have a look on the Round Durations of the last weeks.

Can you laugh there? You find it normal?

[Aseras]

twmz, is there any way you could make the tabs ( active users, current payouts ) work on a iphone/ipad?

They work fine on my iPhone.  What problem are you having?

they come up blank. The initial blocks page loads, clicking the tabs doesn't update. Not working on several phones and ipads I've tried ( borrowed some at work ). From 4.3.4 to 6.1.2

[mdude77]

ok. I do not mean to complain, however, but it will be found to get worse with the times around a block. but everyone says it's normal and no one is strange. I Think the L* change in correlation with  the p2pool versions. but everyone says that it is all normal :-) .

Wath's going on People?
have a look on the Round Durations of the last weeks.

Can you laugh there? You find it normal?

Frankly I'm surprised there's anyone left here.  However, I think as difficulty continues to increase, at 300GH/s (or less), variance will become more and more painful.

M

[rav3n_pl]

Eh, we just need few seriuous miners to put pool power over 700GH.
This way we will have over 3 blocks per day and all shares can be used in less than 24hrs of payout.
I`m surprised, that there is no new miners now, because (looking on L graph) it ALWAYS was big jump after hole like we have now.
Switch to P2pool NOW!

[Aseras]

I'm not coming back until I get my avalons. Right now I'm eeking out every ounce I can out of my GPU's.  I'll be able to double the p2pool hashrate easily within a couple of weeks...if my batch ones come in.

[Subo1977]

What was the longest round from p2pool ? 

[maqifrnswa]

Eh, we just need few seriuous miners to put pool power over 700GH.
This way we will have over 3 blocks per day and all shares can be used in less than 24hrs of payout.
I`m surprised, that there is no new miners now, because (looking on L graph) it ALWAYS was big jump after hole like we have now.
Switch to P2pool NOW!

love it http://en.wikipedia.org/wiki/Gambler%27s_fallacy

[rav3n_pl]

It would be true, if we hash 10 times/day. But we have 300`000`000`000 hashes / second, so we CAN use it as fair number of tries and it "have" to balance .... in some point

[maqifrnswa]

It would be true, if we hash 10 times/day. But we have 300`000`000`000 hashes / second, so we CAN use it as fair number of tries and it "have" to balance .... in some point

The past has no outcome on future results. So, right now the current block has a 50% chance of taking between 3.4 to 4 days to find, and 50% of taking more than 4 days to find. (Median and mean are not the same in exponential probability distributions). The problem with p2pool now is that the relative variance is 27% greater than it was before ASICS (from 14 blocks per week +/- 3.7 to 9 blocks a week +/-3, poisson distribution)

[Aseras]

And we've got a winner

[organofcorti]

It would be true, if we hash 10 times/day. But we have 300`000`000`000 hashes / second, so we CAN use it as fair number of tries and it "have" to balance .... in some point

The past has no outcome on future results. So, right now the current block has a 50% chance of taking between 3.4 to 4 days to find, and 50% of taking more than 4 days to find. (Median and mean are not the same in exponential probability distributions). The problem with p2pool now is that the relative variance is 27% greater than it was before ASICS (from 14 blocks per week +/- 3.7 to 9 blocks a week +/-3, poisson distribution)

Perhaps you can help with a conundrum with which I've wrestled for a while.

The number of shares required to solve n blocks can be described by a (shifted) negative binomial CDF, where size = number of rounds and p = 1/Difficulty.

As an example, the upper tail probability of more than 1.6 x 9 x Difficulty shares being submitted in 9 rounds is 0.05.

If the 10th round is more than 1.6 x Difficulty shares, the probability of this number of shares occurring in ten rounds is less than 0.04, and if the 10th round is less than 1.6 x Difficulty shares, the probability of this number of shares occurring in ten rounds is more than 0.04.

This relates back to rav3n_pl's comment, since it does imply that for an arbitrary number of runs of n rounds where the total shares submitted for the first (n-1) rounds is very unlikely, there will be more runs where CDF for the total of n rounds is closer to the median than further from it.

This means the nth round is more likely to be shorter than longer. Not shorter than average, but just shorter, and therefore luckier.

So I think I'm misunderstanding something about the way this "paradox" should be interpreted. Where am I going wrong?




  

[Aseras]

Perhaps p2pools problem is that there are too many people observing it constantly and thus are altering the outcome.

/Schrödinger

[maqifrnswa]

It would be true, if we hash 10 times/day. But we have 300`000`000`000 hashes / second, so we CAN use it as fair number of tries and it "have" to balance .... in some point

The past has no outcome on future results. So, right now the current block has a 50% chance of taking between 3.4 to 4 days to find, and 50% of taking more than 4 days to find. (Median and mean are not the same in exponential probability distributions). The problem with p2pool now is that the relative variance is 27% greater than it was before ASICS (from 14 blocks per week +/- 3.7 to 9 blocks a week +/-3, poisson distribution)

Perhaps you can help with a conundrum with which I've wrestled for a while.

The number of shares required to solve n blocks can be described by a (shifted) negative binomial CDF, where size = number of rounds and p = 1/Difficulty.

As an example, the upper tail probability of more than 1.6 x 9 x Difficulty shares being submitted in 9 rounds is 0.05.

If the 10th round is more than 1.6 x Difficulty shares, the probability of this number of shares occurring in ten rounds is less than 0.04, and if the 10th round is less than 1.6 x Difficulty shares, the probability of this number of shares occurring in ten rounds is more than 0.04.

This relates back to rav3n_pl's comment, since it does imply that for an arbitrary number of runs of n rounds where the total shares submitted for the first (n-1) rounds is very unlikely, there will be more runs where CDF for the total of n rounds is closer to the median than further from it.

This means the nth round is more likely to be shorter than longer. Not shorter than average, but just shorter, and therefore luckier.

So I think I'm misunderstanding something about the way this "paradox" should be interpreted. Where am I going wrong?

Good question, heading out but want to think about it a bit more later. I think it may has to do with conditional probability, which ties into gambler's fallacy (unless I'm reading this too quickly). While it is far more likely to have 1 lucky round and 9 unlucky rounds than it is to have 10 unlucky rounds, if you are sitting at the tenth round it is equally probably to have a lucky or unlucky round regardless of what happened in the past. You can also approach this as a conditional probability problem when for isolated random events (P(A given B) = P(A)P(B)/P(B) when P(A) is not affected by event B)

Here is a worked out example showing that although it is far more likely to have a certain outcome in n-tries, the probabillity of an event occuring on the nth try is independent of the previous trials.
http://en.wikipedia.org/wiki/Gambler%27s_fallacy#Explaining_why_the_probability_is_1.2F2_for_a_fair_coin
http://en.wikipedia.org/wiki/Gambler%27s_fallacy#Explaining_why_the_probability_is_1.2F2_for_a_fair_coin

[rav3n_pl]

Block ETA is now 19hrs and rising, when we go over 24hrs (pool rate under 200GH) mining will become totally unprofitable...
We need more power!

[lenny_]

Block ETA is now 19hrs and rising, when we go over 24hrs (pool rate under 200GH) mining will become totally unprofitable...
We need more power!

Can you please explain in more technical way?