If someone takes the time to do the math on all that information they freely share, they might see where the problem lies. Like an almost exactly 10% less payout that expected over the life of the pool...
I don't see anything like that when I do the stats. How exactly are you calculating this?
well there is the post that you bring it to attention.. but that was only after we got shafted from slush.. here is a look at slush stats when the shit hit the fan.. There is a whole sluice of issues slush had with the relay network then a ddos for allowing vote to 8 mb then the block withholder.. All that happen back to back.>
Per your guide..
http://organofcorti.blogspot.com/2016/01/january-17th-2016-mining-pool-statistics.htmli dont have time atm to dig any further.. all pools need to show like phil said. all blocks and then a gradual decrease to last 5 or 10. Kano sets an example how simple is best... That lost btc can never be replaced unless the Genesis mining comes forth and wants to save their reputation.. Ive already tweeted to them >> but of course no reply.. Something not taught in school and apparently not by parents is how to own up to your mistakes.. Its turning this world into a pile of crap if you ask me.
Best Regards
d57heinz
BTW.. Kano i didnt know that it was genesis.. i have given you shit in past but that is before i realized the pattern of honesty and transparency from you that is so lacking in this industry.. this space needs more like you for sure.. THankful for that.
Please don't lie. I'm well aware of what I wrote, and I've never written that there has been a 10% loss over the life of the pool.
Do you have lifetime number? Or any long term numbers for them.
98.2% of expected over the life of the pool.
Orphans were more common when the pool started, and tx fees (included in the calculation) were often zero at that time, so 1.8% down over the lifetime of the pool is acceptable. At ~62% the CDF is certainly not unusual.
Pool reported statistics since 2010
Pool No.Blocks orphans luck CDF %Profitability
1: DeepBit 31218 115 1.01 82.7% 101%
2: Discus Fish 28117 197 1 25.5% 100%
3: Slush 26680 319 1 61.6% 98.4%
4: GHash.IO 23371 314 1.04 100.0% 91.1%
5: AntPool 16261 178 1 27.5% 101%
6: BTC Guild 13595 86 - - -
7: 50BTC.com 12060 218 - - -
8: Eligius 11403 235 1.03 99.6% 91%
9: EclipseMC 6561 30 0.72 0.0% 84.1%
10: BitMinter 6483 306 1.02 97.5% 107%
11: Ozcoin 4855 22 1.07 100.0% 98%
12: MTRed 2205 17 0.99 31.4% 99.1%
13: p2Pool 2198 41 - - -
14: Polmine 2069 25 1.1 100.0% 88.4%
15: Mineb.tc 1692 38 1.02 78.9% 94.4%
16: Itzod 1379 6 1.01 69.3% 102%
17: Kano.is 909 8 0.93 1.7% 108%
18: Bitparking 633 19 1.15 100.0% 95.2%
19: HHTT 632 1 - - -
20: Triplemining 508 0 1.04 84.3% 92.1%
21: BTCMP 390 12 0.89 1.2% 85.6%
22: BTCDig 34 1 1.01 54.9% 84.1%
23: MMPool 33 0 0.95 40.7% 94.2%
Per your guide organ.. A pool has to allow a miner to go thru what should have been ten blocks to be able to detect a block with holder.. So yea 250 btc at least. More info to come..
2. How can a pool detect block withholding efficiently?
All the suggestions I've read depend on waiting until a miner has returned a sufficient amount of work to have solved on average(yes but with bad luck it could have been double average or triple. who is to know for sure Ive got data to back up when this started) ten blocks but has actually solved none. This has a lower tail Poisson probability of exp(-10) ~ 0.000045399, so this would happen by chance only once in every 22026 user accounts.
Unfortunately this means losing 10 blocks worth of credit for the pool, and depending on how the pool treats the loss, it may mean a loss for honest miners too. However there are more efficient methods to detect unintentional block withholders (and since an intentional block withholder can simply have many different user accounts in parallel or sequence, it may not be possible to detect an intentional block withholder at all).
http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.htmlHere is where slush finally detected it..
https://slushpool.com/news/2016/02/06/recent-low-luck-information/