[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[organofcorti]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

[1713873958]

1713873958

[philipma1957]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

[organofcorti]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

Code:

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%

[d57heinz]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

Code:

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.html

Here is where slush finally detected it.. https://slushpool.com/news/2016/02/06/recent-low-luck-information/  

[organofcorti]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

Code:

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.html

Here is where slush finally detected it.. https://slushpool.com/news/2016/02/06/recent-low-luck-information/  

And nowhere there did I say that there has been a ten percent loss over the life of the pool. Another forum member just made that up but now you're saying it's something I wrote? Nothing in the quotes backs up the claim.

Please just post a retraction.

[kano]

...
Also, where does 250BTC come from? I assume you have the facts to back up this number.
...

Oh I missed this one
Heh, so you don't even know where that number comes from.
Wow, you really need to understand the statistics of pool mining before going off on a rant about "No Facts"

Quotes? References? Statistics? Nothing?
Truly said like someone who has nothing to back it up, been asking for the proof/data for a month now, still waiting..........

Because you are ignorant of pool statistics, you may indeed be unable to follow the posts where I have already given that information ...
Learn a little about pools and statistics before you rant about things well above your knowledge level then come back and see how stupid some of your comments are.

Firstly, my link shows they were around 20% down on luck for AT LEAST the whole month of December.
I'll point out where I replied to you with that link, since you don't bother reading replies ... but then I guess you wont read this one either ...
https://bitcointalk.org/index.php?topic=1976.msg14908257#msg14908257
The CDF[Erlang] that I mention, ignore it, it's too complicated for you.

Secondly to detect a withhold without using organofcorti's 32bit check idea takes around 10 blocks ... wow guess what, 10 blocks ~= 250 BTC ... amazing hey? Though that's probably too much for you to understand that one either.
That's of course if slush was paying attention the whole time ... otherwise it would be more than 10 blocks ...

But I can give you some simple grade school maths also ...
20% down for 228 blocks = 44 blocks below expected ... hmm that's a lot ...
So lets pretend probabilities don't matter, since they're too complicated for you, and assume the pool actually had a ridiculously high 10% bad luck on 228 blocks and that leaves 10% withholding ... so hmm 22 blocks lost ... 550 BTC ... ouch ...

[Mudbankkeith]

and that is why, after 3 years on "slush" I moved to CK on the 2nd of January this year.
The problem MAY be over "but" so is my trust.

[d57heinz]

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?

http://organofcorti.blogspot.com/2016/02/detecting-unintentional-block.html
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.html

i 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.

Code:

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.html

Here is where slush finally detected it.. https://slushpool.com/news/2016/02/06/recent-low-luck-information/  

And nowhere there did I say that there has been a ten percent loss over the life of the pool. Another forum member just made that up but now you're saying it's something I wrote? Nothing in the quotes backs up the claim.

Please just post a retraction.

Ok i agree that you never said that....  i think the confusion there was year stats of pool and lifetime. not sure when that got mixed up.. thank you for clearing that up..  Knowing the exact amount of damage done is next to impossible atm because that would require being able to predict the next block.

All pools should post the lifetime stats to their website.. If they dont know how to do that then they shouldnt be running a pool or have something to hide!

as far as the genesis mining.. I havent been able to tie them to slush with any post or info online.>  What i have found on GM and its business is rather sad indeed. typical of this space unfortunately.>> If they were the ones that did this to slush i wouldnt expect any kind of compensation whatsoever..

Honestly its not about who did it or any of all that.. Stats at this point dont really matter as slush said he has fixed the problem..  The problems this pool has/had is its lack of awareness/transparency that the owner gave to the miners that support(ed) him.  No responses from him on fb or here when a good number of us where noticing the drastic drop in pool performance when that 10 ph miner jumped on and off back in sept or oct( i dont have time to dig back at my posts) of 2015 thru to jan 2016..  If he had just addressed our concerns back then i think it would have went a  long way in keeping his userbase.. He sided with the miner(corporate interest vs the community) and allowed them to profit.  If i wrote mining code for my own pool and put 10 ph to it not knowing it would find blocks i sure as hell wouldnt go to the community and expect them to compensate me if after 3 months it still hasnt produced.. Now on that line of thinking i dont know how the person slush was in contact with can feel good about what he did to slush and the miners on his pool..   I dont want to beat a dead horse any longer.  enough has been said and i think people are waking up to the fact that Kano actually is trying to make this a community feeling at least as long as we can .. But sadly big industry will push out all the creativity that started in this space and we will be left with the same old same old because its ran by the same ignorant people that put this world in the shit hole it is..

Anyway enough about that ..

Have a great day everyone.
Best Regards
d57heinz

[philipma1957]

And we get a good answer, thank you

philipma1957
Do you have lifetime number?  Or any long term numbers for them.

organofcorti
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.

Code:

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%

[CarrollFilms]

Tried Kano.is for a day with 3 miners, only found 1 block in 24 hours. No idea what would cause that.

I'll keep an S5 on there just to see if the pool luck changes at all, other than that it's back to Slush.

[Erumara]

Big thanks to Organofcorti for that information.

I am forced to point out, especially after Kano's basically personal attack on me (pretty solid evidence I'm on the right track), that you have still NOT provided the PROOF that Slush is responsible, or in any way to blame or to be held accountable for what amounts to an attack against his pool.

MAYBE Genesis controlled the hashpower we're talking about.
MAYBE this was an attack, MAYBE this was an accident.

Evidence submitted and accepted at large:

There was block withholding incident at Slushpool, no-one has argued this point.
There was a loss of income as a result of this block withholding, no-one has argued this point.

You are throwing out hypothetical numbers relating to what Slush and it's users lost as a result of this attack. Ever since, people claiming to be your users (Kano) have been using these hypothetical numbers to spread FUD and misinformation regarding Slush's culpability in these attacks.

Does that make you proud Kano? Now you're in here, promoting FUD and blaming the primary victim (Slush) for the loss of his own income!

I ask again, for the dozenth time, where is the proof Slush is to blame? Where is the logic in attacking a pool operator for the actions of an unknown individual? Why exactly, despite DOZENS of shill posts in this thread and elsewhere encouraging people to use Kano, should anyone choose Kano over Slush?

Lower fees.

It is accepted (based on the information provided) that no pool can detect or prevent a block withholding attack better than another.

A pool is a pool is a pool. Kano's ckpool continues to lose face as a result of the actions of both users and now admins in this thread. If I saw Slush promoting shills and posting in your (self-moderated, way to increase transparency!) pool thread, I would move my hashpower elsewhere as I refuse to support what amounts to shill tactics and FUD to the benefit of YOUR BUSINESS.

So where should you point your miners? As I've said before, IT MAKES NO F**KING DIFFERENCE and personally it's none of my concern.
When people come to these forums seeking information and advice, they should be met with that FACT, not rumor and testimony about how "Slush is really suspicious and didn't answer users asking for privileged information regarding other users"

See if you can guess where my hashpower is NOT going.

[Erumara]

Tried Kano.is for a day with 3 miners, only found 1 block in 24 hours. No idea what would cause that.

I'll keep an S5 on there just to see if the pool luck changes at all, other than that it's back to Slush.

Your original post seemed to get lost in the mayhem, thought I would try and help you out.

Slush will find more blocks per day (assuming 100% luck) but you will get a proportionally smaller share of each block.
Kano will find fewer blocks per day (assuming 100% luck) but you will get a proportionally larger share per block.
Small pools (Johnnybravo and the like) will find blocks on the timescale of weeks, you will get a proportionally larger share of these blocks.

On a long enough timeframe your earnings will be equal on any pool, with Kano's 1.1% lower fees you will make 1.1% more than Slush.
The choice is yours, ignore anyone telling you that one pool is better than another based on anything BUT fees, they don't know what they're talking about.

Cheers,

Erumara

[d57heinz]

And we get a good answer, thank you

philipma1957
Do you have lifetime number?  Or any long term numbers for them.

organofcorti
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.

Code:

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%

the fallacy in this logic is that we all started mining on this pool from beginning.. For me i started back in july of 2015.. @organofcorti can you please give me the stats of mining on slush pool from jluly of 2015 to january of 2016 please and thank you..

Best Regards
d57heinz

[CarrollFilms]

Tried Kano.is for a day with 3 miners, only found 1 block in 24 hours. No idea what would cause that.

I'll keep an S5 on there just to see if the pool luck changes at all, other than that it's back to Slush.

Your original post seemed to get lost in the mayhem, thought I would try and help you out.

Slush will find more blocks per day (assuming 100% luck) but you will get a proportionally smaller share of each block.
Kano will find fewer blocks per day (assuming 100% luck) but you will get a proportionally larger share per block.
Small pools (Johnnybravo and the like) will find blocks on the timescale of weeks, you will get a proportionally larger share of these blocks.

On a long enough timeframe your earnings will be equal on any pool, with Kano's 1.1% lower fees you will make 1.1% more than Slush.
The choice is yours, ignore anyone telling you that one pool is better than another based on anything BUT fees, they don't know what they're talking about.

Cheers,

Erumara

Thanks for making sense of things. I was completely thrown off by the whole debate.

I am more than likely going to end up sticking with Slush because of the fancy desktop UI and mobile app.

I've almost mined an entire Bitcoin on Slush at this point. I see no point in leaving the pool; especially for being with it for as long as I have been with it.

[Erumara]

the fallacy in this logic is that we all started mining on this pool from beginning.. For me i started back in july of 2015.. @organofcorti can you please give me the stats of mining on slush pool from jluly of 2015 to january of 2016 please and thank you..

Best Regards
d57heinz

In this perfect example, this user has fallen victim to The Gambler's Fallacy https://en.wikipedia.org/wiki/Gambler's_fallacy and believes that past performance of a pool has some impact on future performance of a pool. This is false. The odds of Kano's luck remaining >100% are identical to the odds of Kano's luck being <100% in the future, the only factor that changes is time.

User announces: "This pool has >100% lifetime luck! Point your miners here"
Translation:        "I happened to pick this pool as a result of various factors and choices, and just so happened to stumble upon good luck!"

User announces: "This pool has <100% lifetime luck! Point your miners elsewhere!"
Translation:        "I mine on a different pool and personally want your hashpower there so we can find more blocks!"

Not trying to pick on anyone I'm just trying to educate while I continue to learn myself.

[kano]

...
In this perfect example, this user has fallen victim to The Gambler's Fallacy https://en.wikipedia.org/wiki/Gambler's_fallacy and believes that past performance of a pool has some impact on future performance of a pool. This is false. The odds of Kano's luck remaining >100% are identical to the odds of Kano's luck being <100% in the future, the only factor that changes is time.
...
Not trying to pick on anyone I'm just trying to educate while I continue to learn myself.

Try learning before you educate people with misinformation

Wouldn't the world be bright with sparkly rainbows if random luck was the only factor in mining

[Erumara]

Did you have some worthwhile information to add, or are you simply back to take another shot at me?
Can't help but notice the whole "Slush is untrustworthy" tangent seems to have finally disappeared and instead you seem determined to make this about me, despite the fact I have only offered information from outside sources coupled with my own opinions.

Are you insinuating there is some controllable factor for a pool or miner to squeeze out >100% lifetime luck? I really hope not as this is *by my understanding* the whole reasoning behind the difficulty system (to ensure the odds of a block being found by entity A are the same as entity B, all other factors being equal).

No human generated system can be absolutely random, as pointed out earlier in the thread, bandwidth/latency, relative location of nodes, etc. all have an impact.
However, from the point of view of the network, those factors vary from miner to miner, pool to pool, and can change constantly.
I'm pretty confident Organofcorti would agree any gain from having a better connection (and claiming the 1/10,000 blocks [Just a number for illustrative purposes, don't get all worked up] that end up being submitted *just* faster than another) would be impossible to prove either way due to variance.

Pretty sure I had it right thanks, anyone who has actual information PLEASE correct me as you even quoted me on:

I'm just trying to educate while I continue to learn myself.

[organofcorti]

Did you have some worthwhile information to add, or are you simply back to take another shot at me?
Can't help but notice the whole "Slush is untrustworthy" tangent seems to have finally disappeared and instead you seem determined to make this about me, despite the fact I have only offered information from outside sources coupled with my own opinions.

Are you insinuating there is some controllable factor for a pool or miner to squeeze out >100% lifetime luck? I really hope not as this is *by my understanding* the whole reasoning behind the difficulty system (to ensure the odds of a block being found by entity A are the same as entity B, all other factors being equal).

No human generated system can be absolutely random, as pointed out earlier in the thread, bandwidth/latency, relative location of nodes, etc. all have an impact.
However, from the point of view of the network, those factors vary from miner to miner, pool to pool, and can change constantly.
I'm pretty confident Organofcorti would agree any gain from having a better connection (and claiming the 1/10,000 blocks [Just a number for illustrative purposes, don't get all worked up] that end up being submitted *just* faster than another) would be impossible to prove either way due to variance.

Pretty sure I had it right thanks, anyone who has actual information PLEASE correct me as you even quoted me on:

I'm just trying to educate while I continue to learn myself.

I'm guessing what Kano means is that if the luck statistic is unusually high (poor luck, say at ten blocks a CDF of greater than 0.99999 or a thousand blocks at a CDF of 0.999) then it may be that something untoward is happening -- in this case a block withholding attack event.

If we could know that the result is simple "bad luck", then you what you've written is correct. This is not always the case so for any pool recent extremely poor luck statistics could predict future "bad luck" if:

1. There is a reason for the poor luck statistic
2. This reason has not been addressed by the pool operator.

In the case of GHash.IO for example, I informed them of their abnormally poor luck scores a long time before they actually did anything about it. In their case, there was an actual attack in which the same hashes could be resubmitted and counted as valid and unique as long as upper and lower case letters were considered different. This went on for quite a while before it was eventually fixed, and turned out it was a known bug that had been addressed in other pools much earlier and AFAIK before exploited.


 

[philipma1957]

Did you have some worthwhile information to add, or are you simply back to take another shot at me?
Can't help but notice the whole "Slush is untrustworthy" tangent seems to have finally disappeared and instead you seem determined to make this about me, despite the fact I have only offered information from outside sources coupled with my own opinions.

Are you insinuating there is some controllable factor for a pool or miner to squeeze out >100% lifetime luck? I really hope not as this is *by my understanding* the whole reasoning behind the difficulty system (to ensure the odds of a block being found by entity A are the same as entity B, all other factors being equal).

No human generated system can be absolutely random, as pointed out earlier in the thread, bandwidth/latency, relative location of nodes, etc. all have an impact.
However, from the point of view of the network, those factors vary from miner to miner, pool to pool, and can change constantly.
I'm pretty confident Organofcorti would agree any gain from having a better connection (and claiming the 1/10,000 blocks [Just a number for illustrative purposes, don't get all worked up] that end up being submitted *just* faster than another) would be impossible to prove either way due to variance.

Pretty sure I had it right thanks, anyone who has actual information PLEASE correct me as you even quoted me on:

I'm just trying to educate while I continue to learn myself.

   I don't know what kano is saying, but here is the truth about bitcoin mining luck.

The only part that is even for all pools is the 256 algorithm   or in other words the difficulty level.  Thats is even Steven across the board for all pools.

All the rest is not even. 
What happened to your pool when the pool suffered from the withholding issue is a perfect example of  something that crushed your luck.

BTW btc guild got hammered  with a withholding issue that crushed their luck for a long time.

Tell you what  why not make this list

Block Statistics

Description   Time   MeanTx%   Diff%   Mean%   CDF[Erl]   Luck%
Last 5 Blocks   1.1days   100.8%   102.84%   102.84%   0.5840   97.24%
Last 10 Blocks   2.7days   101.1%   114.19%   114.19%   0.7032   87.57%
Last 25 Blocks   5.8days   101.5%   94.05%   94.05%   0.4066   106.32%
Last 50 Blocks   12.0days   101.5%   91.08%   90.90%   0.2686   110.02%
Last 100 Blocks   27.9days   101.5%   109.76%   110.40%   0.8507   90.58%
Last 250 Blocks   8.5wks   101.3%   94.05%   93.61%   0.1559   106.83%
Last 500 Blocks   18.9wks   101.2%   92.90%   91.92%   0.0327   108.79%
All - Last 929 Blocks   87.3wks   100.9%   93.70%   94.26%   0.0381   106.09%


take it back since you are older

put in

Last  750
Last 1000
Last 1500
Last 2000
Last 3000
Last  4000
Last  5000

We know you are at 98% lifetime  which is good.


But     the stats above would show if you really had a slump  of 10% for months

[tomcat2]

11 blocks in the last 12 hours.