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

Finally it is stabilizing DOA+orphan is only about 15%

Neither did I. Mean roundlength, on the other hand, tends toward a normal distribution at the number of samples increases.

No, the number of blocks solved in a given time period is a Poisson distribution random variable.

I didn't quite follow the rest. Sorry.

I have not looked at round length, as that is zero bounded so not normally distributed.

I instead looked at Blocks in Given period. So long as the period is reasonably long such that the odds of finding zero blocks in that period is very close to zero, these are normally distributed.

I also looked at the odds of a given share being "low" enough to find a block.

So since the probability (i.e. mean) of a share being a block is just the relative difficulties / 60 (as shares occur every 10 secs but block every 10 mins).

So in my example this was 1/2400. i.e. one share in 2400 is expected to find a block.

This is a Bernoulli process. So the variance of a share finding a block is p . (1 - p) where p is the probability of a share finding a block.
So for one share:
Mean = 1/2400 = 0.00041666
Variance = 1/2400.(1-1/2400)=0.0004164931

The spreadsheet shows that the above is true by simulating.

I then say that the 90 day "Blocks Found" variance can be calculated by saying that it is just the sum of 777600 (6 per min . 60 mins . 24 hours. 90 days) independent and uncorrelated random variables (i.e. each share), so I can just sum the means and variances.

So the Mean for this is 777600 * 0.000416666 = 323.94 blocks per 90 day period.
And the Variance = 777600 * 0.0004164931 = 323.79
Standard Deviation = sqrt(323.79)=17.99

So to convert the 90 Blocks Standard Deviation into "90 Day Luck" I just have to divide by the expected blocks in that period:
StdDev of 90 day Luck =  17.99/323.79 = 0.0555 = 5.5%

So I would expect the 90 day Luck to be 100% with a standard distribution of 5.5%.
So the current figure of 87.3 is 2.3 standard distributions from the mean, so unlikely but possible.

Make sense? Do you think I am correct in my logic?

0.099 x 14 Days = 1.386BTC

If you were mining at a 0% Fee PPS pool you would make more then what your making now.

Yes, five posts above yours. I'm not following what your calculations mean or what they're based on, though, or what the simulation is for. A p value is easily determined by assuming a normal distribution of means and applying the CDF. In this case:

H0: The population mean (round length/difficulty) = 1
Ha: The population mean (round length/difficulty) > 1

The p.value is 0.013, so there's a good probability that the mean roundlength/D for p2Pool is greater than 1.0

How did you calculate your confidence interval? I'm intrigued.

I did some statistical analysis and simulation of the expected Luck for p2pool.

From it the current Luck over 90 days of 87.3% is at about the 99% confidence band. i.e. with luck this low there is only a 1% chance that it is caused by bad luck and a 99% chance it is a bug.

See this spreadsheet for my proof and simulation.
http://bitcoinstatus.rowit.co.uk/p2pool/odds.xlsm

In doing this I had to make a number of assumptions:
1) BTC hash rate constant at 12T Hash/sec
2) P2Pool hash rate constant at 300 G Hash/sec (about average over last 90 days).
3) BTC and P2Pool difficulty constant over period.

In summary for 90 day luck I would expect luck to be 100% with a standard deviation of 5.6%.
So as you can see 87.3% is unlikely by possible.

On the spreadsheet you can update the current BTC hash rate and also the pool hash rate and it will recalculate the Luck standard deviations for each of the 3 time periods. It will also update the chart on the second tab. Also note that when looking at the chart on the second tab press F9 to rerun the simulation and get another chart (and enable macros when you open it).

Other possibility is that the charts on p2pool.info have a bug. Has anyone audited their numbers?

Below is image of simulation that shows assumptions seem to be reasonable:

For about 2 weeks of mining my 6770 (~170MH/s) I get 1.3BTC from p2pool.
I tried bigger pools earlier, where pay2share is and i get MUCH LESS (even 5x less!).
P2pool is best for me

*Image removed*

(Late to the party, I jumped on ancow for no reason when it was check_status who used the symbol in crazy ways.)

And here I was thinking p2Pool users were a cut above the average miner 

Alright... off to the corner for a half hour, for sticking a bunch of math into the middle of our silliness...

-- Smoov

The mean (roundshares/difficulty) for the last 442 rounds is approx: 1.12
The sd (roundshares/difficulty) for the last 442 rounds is approx: 1.10

So the probability a mean (roundshares/difficulty) being greater than the current mean is given by the normal CDF for a quantile of 1.12 in a normal dist with a mean of 1 and sd = sqrt(442)/1.1. The result is 0.013.

So there's only a 1.3% chance that a larger mean than this could exist if the population mean is actually 1.0.

What does this mean? Well, it can't be completely accurate, for one thing. Included in the mean calculations are negative round shares, and the round shares are calculated from hashrate, not share submissions. But I think it does nothing to disprove the possibility that on average p2Pool users are earning less than at other pools (except deepbit PPS).

☃

I like that one...

Say I am telling someone to send me 9 BTC I'd just say

Send me ⊍9⊍

-- Smoov

⊅ 'not a superset of'
So BTC is not a superset of anything?
While we're at it then, in the same vein, we could use ☃ - meaning not a snowballs chance in ...

reason to not try ot fix things when alseep #1324662324...

I was close. It was a port issue, just didn't involve a firewall. 

nope. not that. wait... it... oh for fucks sake. i had typed 9333 before. *headdesk* shoot me now. it's working fine.

⊅ Reminds me of a Dee which stands for digital.

There are quite a few others to choose from like, ⊍⊍
http://www.alanwood.net/unicode/mathematical_operators.html

GUIminer, for me at least, doesn't seem to like to remember the port I want it on in between runs, putting it back to 8332 when I run it again. Did it do that this time?

Should be 9332

-- Smoov

guiminer v2012-02-19.

stop and started several times, yea. but like i siad - i'm giving up and sticking with p2pmining.com, for now. i'll sort this out when i get an fpga.