20% fee pool last 18 moths? WOW!
deepbit version 2.0? 
Topic: Neighbourhood Pool Watch - page 3. (Read 49925 times)
20% fee pool last 18 moths? WOW!
I finally got around to finishing part 2 of the BitcoinPool series: Neighbourhood Pool Watch 8.2 BitcoinPool: The great anomaly hunt.
Lots of weirdness happening at this pool, and it seems that the BitcoinPool miners are suffering:
Lots of weirdness happening at this pool, and it seems that the BitcoinPool miners are suffering:
Quote
6. Discussion and summary.
What has the great anomaly hunt revealed? Some strange and improbable anomalies, certainly. For a start, It is extremely improbable that the statistics of rounds 480 onward are distributed as they should be.
To answer my initial questions:
Did the anomalous rounds occur equally at all times, or only for a particular epoch of time?
Rounds 1 to 479 have very different statistics to those from 480 onward
Did the anomalous rounds occur equallyfor all sized rounds, or for some particular sized rounds only?
For rounds 480, the number of rounds having shares per round between 0 to 0.11 x D, and 0.36 to 0.51 x D are improbably small, and the number of rounds having shares per round greater than 2.3 x D are improbably many.
These facts do not really help us explain what the cause of the anomalies are. I have not been able to determine the way this could occur - either accidentally or on purpose. For example:
Block withholding attack (see Meni Rosenfeld's "Analysis of Bitcoin Pooled Mining Reward Systems" for details): A "sabotage" attack is unlikely - the anomaly has been occurred at BitcoinPool for nearly 18 months (at the time of writing), and I find it unlikely that anyone would be able to keep up this kind "no reward" of attack for so long. Also, to what end? If I'm the first analyst to find this, it's not an obvious problem for the pool. A "lie in wait" attack might be more likely, but I'm not sure how to calculate how profitable it would be for BitcoinPool's piecemeal reward function. Certainly possible though.
From pool op Geebus:
"The efficiency of any given miner, if not returning a share that could have potentially have had the answer to that block due to not hashing it before another entity in the bitcoin network solves a block, and long polling triggers, could change the outcome. "
Although this might seem intuitive to some, the efficiency of an arbitrary miner cannot affect the number of shares required for the pool to solve a block. Only valid shares received by the pool are recorded; non shares that are not sent by low efficiency miners are not recorded.
Pool operator malfeasance (someone with access to the pool server and data base): I think this is unlikely. If, for example, round with few shares are not being recorded and simply being added to the next round, then we would expect to see a spike in the next largest sized round, then a slight dip for the next largest shares per round /D bin, and slightly more than expected for the remainder of larger shares per round /D bins. The histogram shows that this is not the case. Applying some sort of function to the result of the number of shares per round (as was almost certainly the case for bitclockers.com before they became a PPS pool) would not have had such an apparently discontinuous effect on the pools shares per round / D distribution.
The most likely of the explanations that I've been able to analyse (and some I couldn't) seems to be a "lie in wait" attack. Even this is quite unlikely though - the hashrate required to make such an attack usefully profitable is quite high, and the pool's total percentage of the network is less than 0.2%.
So I'm not sure what the mechanism behind the anomalies is, or whether it's an internal or external attack, or if perhaps the shares are not being recorded properly in some strange way that targets only specific sized rounds. I am however quite confident that this is not just a period of bad luck for BitcoinPool - there are just too many extremely improbable anomalies for that to have occurred.
Until Geebus and FairUser can investigate and solve this problem, I'd avoid mining at BitcoinPool.com - the last 18 months history of the pool suggest you'll earn an average of only 80% of your expected mining reward.
What has the great anomaly hunt revealed? Some strange and improbable anomalies, certainly. For a start, It is extremely improbable that the statistics of rounds 480 onward are distributed as they should be.
To answer my initial questions:
Did the anomalous rounds occur equally at all times, or only for a particular epoch of time?
Rounds 1 to 479 have very different statistics to those from 480 onward
Did the anomalous rounds occur equallyfor all sized rounds, or for some particular sized rounds only?
For rounds 480, the number of rounds having shares per round between 0 to 0.11 x D, and 0.36 to 0.51 x D are improbably small, and the number of rounds having shares per round greater than 2.3 x D are improbably many.
These facts do not really help us explain what the cause of the anomalies are. I have not been able to determine the way this could occur - either accidentally or on purpose. For example:
Block withholding attack (see Meni Rosenfeld's "Analysis of Bitcoin Pooled Mining Reward Systems" for details): A "sabotage" attack is unlikely - the anomaly has been occurred at BitcoinPool for nearly 18 months (at the time of writing), and I find it unlikely that anyone would be able to keep up this kind "no reward" of attack for so long. Also, to what end? If I'm the first analyst to find this, it's not an obvious problem for the pool. A "lie in wait" attack might be more likely, but I'm not sure how to calculate how profitable it would be for BitcoinPool's piecemeal reward function. Certainly possible though.
From pool op Geebus:
"The efficiency of any given miner, if not returning a share that could have potentially have had the answer to that block due to not hashing it before another entity in the bitcoin network solves a block, and long polling triggers, could change the outcome. "
Although this might seem intuitive to some, the efficiency of an arbitrary miner cannot affect the number of shares required for the pool to solve a block. Only valid shares received by the pool are recorded; non shares that are not sent by low efficiency miners are not recorded.
Pool operator malfeasance (someone with access to the pool server and data base): I think this is unlikely. If, for example, round with few shares are not being recorded and simply being added to the next round, then we would expect to see a spike in the next largest sized round, then a slight dip for the next largest shares per round /D bin, and slightly more than expected for the remainder of larger shares per round /D bins. The histogram shows that this is not the case. Applying some sort of function to the result of the number of shares per round (as was almost certainly the case for bitclockers.com before they became a PPS pool) would not have had such an apparently discontinuous effect on the pools shares per round / D distribution.
The most likely of the explanations that I've been able to analyse (and some I couldn't) seems to be a "lie in wait" attack. Even this is quite unlikely though - the hashrate required to make such an attack usefully profitable is quite high, and the pool's total percentage of the network is less than 0.2%.
So I'm not sure what the mechanism behind the anomalies is, or whether it's an internal or external attack, or if perhaps the shares are not being recorded properly in some strange way that targets only specific sized rounds. I am however quite confident that this is not just a period of bad luck for BitcoinPool - there are just too many extremely improbable anomalies for that to have occurred.
Until Geebus and FairUser can investigate and solve this problem, I'd avoid mining at BitcoinPool.com - the last 18 months history of the pool suggest you'll earn an average of only 80% of your expected mining reward.
I'm normally not the kind of person to go "I told you so"-ing all over the place, however:
Let's disect this statement shall we:
a decentralized pool = an acceptable price
This connotes a sacrifice in some other area. According to the majority of organofcorti's posts, that is profitability. Your using words to paint an unprofitable picture about p2pool that doesn't exist, the blocks attest to this.
Below are 2 examples out of many that show organofcorti talking about p2pool earnings in relation to other pools:
I have provided 2 samples, 7 day recent and a 31 day historical that show his assertions are nonsense. organofcorti's assessment of p2pool profitability is erroneous, designed to confound and dishearten the uninformed.
Any chance of an apology, check_status?
@organofcorti Why do you work so hard to show how bad p2pool is? Do you have a dog in the race?
Quote from: organofcorti
Given the decentralised nature of the pool, some proponents feel that this is an acceptable price.
Let's disect this statement shall we:
a decentralized pool = an acceptable price
This connotes a sacrifice in some other area. According to the majority of organofcorti's posts, that is profitability. Your using words to paint an unprofitable picture about p2pool that doesn't exist, the blocks attest to this.
It's not out of line at all. There is a preponderance of evidence of organofcorti's p2pool posts where he flat out says or implies p2pool is the least profitable pool.
Please provide a link to a post where I flat out say that p2Pool is the least profitable pool.Below are 2 examples out of many that show organofcorti talking about p2pool earnings in relation to other pools:
Quote from: organofcorti
you're earning less than at a PPS pool.
andQuote from: organofcorti
you should continue mining at p2Pool, despite the lower earnings.
I have provided 2 samples, 7 day recent and a 31 day historical that show his assertions are nonsense. organofcorti's assessment of p2pool profitability is erroneous, designed to confound and dishearten the uninformed.
......
It appears that complex statistical analysis is NOT necessary to determine p2pools profitability.
It appears that complex statistical analysis is NOT necessary to determine p2pools profitability.
Any chance of an apology, check_status?
Looks like it need update, or another chapter
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
Since rav3n_pl asked so nicely, this post is an update to the original p2Pool post.
It answers some questions miners were asking and isn't able to answer other questions they weren't asking.
Quote
7. Discussion and conclusions
7. Discussion and conclusions
It is quite clear from this analysis that p2Pool's run of bad luck - in terms of difficulty 1 shares per round / D and orphaned block production - is over, and I hope I've dispelled the myth that an increased pool hashrate increase orphans and kills the pool's luck. I'll leave interested readers to provide an explanation of the odd correlation between orphaned block production, shares per round / D and certain time periods - please do comment below if you have any suggestions yourself.
I hope this post goes some way to encouraging more miners to test p2Pool for themselves.
7. Discussion and conclusions
It is quite clear from this analysis that p2Pool's run of bad luck - in terms of difficulty 1 shares per round / D and orphaned block production - is over, and I hope I've dispelled the myth that an increased pool hashrate increase orphans and kills the pool's luck. I'll leave interested readers to provide an explanation of the odd correlation between orphaned block production, shares per round / D and certain time periods - please do comment below if you have any suggestions yourself.
- All of the sample statistics fit well in the expected range, and we can't reject the hypothesis that p2Pool's shares per round / D are exponentially distributed.
- There is no correlation between pool luck and pool hashrate, or orphaned block production and pool hashrate, as some have suggested.
- Since solved block 500, the cumulative mean shares per round / D and the cumulative orphans produced per block seem to have both increased and decreased at the same time.
- My guess is that the change in cumulative mean shares per round / D is a coincidence, and the change in orphaned block production is related somehow to changes in the p2Pool client.
I hope this post goes some way to encouraging more miners to test p2Pool for themselves.
Enjoy!
No
I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
Code:
'slush' => 'Slush',
'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
You can see how old the info is 'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
Ah well. If you do manage to get the data together let me know and I'll help you with analysis.
No
I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
care to share? I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
Code:
'slush' => 'Slush',
'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
You can see how old the info is 'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
No
I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
I just write all my own php to talk to bitcoind
But to identify ~50% of blocks you just look in the coinbase transaction:
The strings I used to look for were:
Code:
'slush' => 'Slush',
'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
You can see how old the info is 'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info.
Got a (somewhat self-serving) suggestion for a "pool" watch subject
Transactions per block, kb per block, BTC fees per block, BTC fees per txn (and of course network % blocks per whatever range)
With all this crap going on about what is good for BTC, clearly this will show what is (at least IMO) good for BTC.
IMO good for BTC is blocks that confirm transactions - since no txn's means no one is using BTC which means bye-bye BTC
I'd go as far as suggesting that pools that are near the top of this report (except for network %) should get the most miners and others with much lower stats should get fewer/less - but of course that is just IMO
Anyway, it is mostly all there in the blockchain - the only problems are the issues of determining who owns half the blocks
(~50% of them either name who they are or are obviously p2pool)
The rest I guess you have to trust the pools to say which are their blocks (e.g. deepbit)
I would also suspect that many of the unknowns would be at the bottom of the ranking ...
Transactions per block, kb per block, BTC fees per block, BTC fees per txn (and of course network % blocks per whatever range)
With all this crap going on about what is good for BTC, clearly this will show what is (at least IMO) good for BTC.
IMO good for BTC is blocks that confirm transactions - since no txn's means no one is using BTC which means bye-bye BTC
I'd go as far as suggesting that pools that are near the top of this report (except for network %) should get the most miners and others with much lower stats should get fewer/less - but of course that is just IMO
Anyway, it is mostly all there in the blockchain - the only problems are the issues of determining who owns half the blocks
(~50% of them either name who they are or are obviously p2pool)
The rest I guess you have to trust the pools to say which are their blocks (e.g. deepbit)
I would also suspect that many of the unknowns would be at the bottom of the ranking ...
Something like I did here? Yes, I've wanted to do a more general statistical analysis of blockchain variables, however getting the data is problematic. I can't seem to get any blockchain browser to compile on my macs. Do you have an alternative source?
Got a (somewhat self-serving) suggestion for a "pool" watch subject
Transactions per block, kb per block, BTC fees per block, BTC fees per txn (and of course network % blocks per whatever range)
With all this crap going on about what is good for BTC, clearly this will show what is (at least IMO) good for BTC.
IMO good for BTC is blocks that confirm transactions - since no txn's means no one is using BTC which means bye-bye BTC
I'd go as far as suggesting that pools that are near the top of this report (except for network %) should get the most miners and others with much lower stats should get fewer/less - but of course that is just IMO
Anyway, it is mostly all there in the blockchain - the only problems are the issues of determining who owns half the blocks
(~50% of them either name who they are or are obviously p2pool)
The rest I guess you have to trust the pools to say which are their blocks (e.g. deepbit)
I would also suspect that many of the unknowns would be at the bottom of the ranking ...
Transactions per block, kb per block, BTC fees per block, BTC fees per txn (and of course network % blocks per whatever range)
With all this crap going on about what is good for BTC, clearly this will show what is (at least IMO) good for BTC.
IMO good for BTC is blocks that confirm transactions - since no txn's means no one is using BTC which means bye-bye BTC
I'd go as far as suggesting that pools that are near the top of this report (except for network %) should get the most miners and others with much lower stats should get fewer/less - but of course that is just IMO
Anyway, it is mostly all there in the blockchain - the only problems are the issues of determining who owns half the blocks
(~50% of them either name who they are or are obviously p2pool)
The rest I guess you have to trust the pools to say which are their blocks (e.g. deepbit)
I would also suspect that many of the unknowns would be at the bottom of the ranking ...
Looks like it need update, or another chapter
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
I've been meaning to do follow ups for all posts, I just haven't had the time. Rest assured, I'll get on to it at some point. It would be interesting to see if there was some point where there's an obvious change in mean/orphans and relate it to a particular patch.
Looks like it need update, or another chapter
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
http://p2pool.info/luck/
All-time luck is back to 100%, bugs that possibly cause bad luck/orphans are fixed IMO.
Long live P2pool!
* kano looks into his crystal ball
... future prediction! ASIC price per MH/s will drop over time.Also, look at the pretty pictures ... they do actually help you find when you will make a profit ...
and yes you do have the right idea
Don't buy ASIC - so everyone who has ASIC gets paid more due to the lower difficulty and lastly, at the gold fields, the shovel makers get all the gold
OK, so the thing here is to hope that none of these ppl making these ASICs mine anything for themselves, and you're one of the few that gets them in the "first week" of availability?
otherwise, why buy one? wouldnt it be wiser to just use that money to buy bitcoins instead? if they retain their value, you're out nothing. if they retain their value but difficulty goes up with asic, you're waiting some years?
wouldn't seem very logical for me that if bitcoins were to increase in value (making mining more profitable), that ASICs would also increase in value. added competition over time should result in reduced costs
otherwise, why buy one? wouldnt it be wiser to just use that money to buy bitcoins instead? if they retain their value, you're out nothing. if they retain their value but difficulty goes up with asic, you're waiting some years?
wouldn't seem very logical for me that if bitcoins were to increase in value (making mining more profitable), that ASICs would also increase in value. added competition over time should result in reduced costs
Aren't you forgetting that the BFL SC and bASIC are going to need a PC of some sort, which is going to add at least another 100 watts?
The avalon is a complete standalone unit.
The avalon is a complete standalone unit.
No, I didn't forget that. The blog post does state my assumptions most clearly.
I didn't know that Avalon was stand alone - and that will make a difference. Thanks for letting me know. Do you have a link to confirm this?
It's always been advertised as such
http://store.avalon-asic.com/
http://forum.bitsyn.com/viewtopic.php?id=5
Quote
Avalon self-contained unit >= 60GH/s guaranteed.
pre-order price: $1,299.
note: host PC NOT required. LAN/WIFI connection required.
pre-order price: $1,299.
note: host PC NOT required. LAN/WIFI connection required.
............
More charts and more detail at http://organofcorti.blogspot.com.au/2012/11/93-more-on-asic-choices.html
BFL=65nm was announced today - so the BFL figures before sound like they should be reliable at least ...
Aha! It was the device specs you were querying, not the results. Glad we cleared that up. Also glad you liked the pretty Kanoplot.
Yep I saw the pretty picture and that was more than enough info ...
I heard you like pretty charts, so this one is dedicated to you
Quote
Chart 1: (new) In order to read this group of charts, find the intersection of a percentage ROI and number of difficulty periods (eg. % ROI after one year is at ~ 26 difficulty periods). The colour of the tile is an indicator of the exchange rate required to meet this %ROI after the given number of difficulty periods. The faint white line along the middle of each plot indicates the break even point. Click on a chart for enlargement.
http://4.bp.blogspot.com/-BDCNFtGwYnw/UJkcWy_WCxI/AAAAAAAADIA/Nrdp1JwFTPs/s1600/npw9.3.chart.avalon.rate+2012-11-07+.png
More charts and more detail at http://organofcorti.blogspot.com.au/2012/11/93-more-on-asic-choices.html
BFL=65nm was announced today - so the BFL figures before sound like they should be reliable at least ...
Yep I saw the pretty picture and that was more than enough info ...
I heard you like pretty charts, so this one is dedicated to you
Quote
Chart 1: (new) In order to read this group of charts, find the intersection of a percentage ROI and number of difficulty periods (eg. % ROI after one year is at ~ 26 difficulty periods). The colour of the tile is an indicator of the exchange rate required to meet this %ROI after the given number of difficulty periods. The faint white line along the middle of each plot indicates the break even point. Click on a chart for enlargement.
More charts and more detail at http://organofcorti.blogspot.com.au/2012/11/93-more-on-asic-choices.html
Hmm ... I think it needs a big red watermark across it saying ... these numbers are fictional - don't take any notice of it.
Hmmm ... I think kano didn't read the blog post:
Quote
Although the initial reason for the first ASIC choices post was to show miners some of the calculations that could be used to help determine which ASIC would be the right choice for their mining environment, most attention was focussed on the charts I used to illustrate the calculations. I'm kicking myself for not having used fake ASIC names and specifications but having used real devices I have a responsibility to ensure the specifications used are as correct as consensus opinion make them.
Alrighty then - if you're not talking about the hashrate / price / power consumption figures (which are used as examples to explain how others can make these calculations for themselves) what numbers are you talking about? If I've derived something incorrectly I'd like to know. Stop being so mysterious.
Hmm ... I think it needs a big red watermark across it saying ... these numbers are fictional - don't take any notice of it.
Hmmm ... I think kano didn't read the blog post:
Quote
Although the initial reason for the first ASIC choices post was to show miners some of the calculations that could be used to help determine which ASIC would be the right choice for their mining environment, most attention was focussed on the charts I used to illustrate the calculations. I'm kicking myself for not having used fake ASIC names and specifications but having used real devices I have a responsibility to ensure the specifications used are as correct as consensus opinion make them.
Jump to: