organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
January 26, 2014, 02:36:55 PM |
|
Discus Fish is the pool operator’s nickname, his/her pool is f2pool.com Pity that no much public data can be found there for unregistered user.
Thanks! I'll have to update the pool name. Do you mine there? Of course not, you can read from my signature Perhaps I should have written "Have you mined there?" From what I read on f2pool’s website, it is a PPS pool with 4% fee (24 BTC paid per block), payout is made once a day for miners with balance of 0.0005 BTC or more. It seems only Stratum is supported as mining protocol. I guess tx fee is kept by the pool.
Google translate tells me similar. I'll try their support address, but I'm not sure they'll respond to an english email out of the blue.
|
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
wknight
Legendary
Offline
Activity: 889
Merit: 1000
Bitcoin calls me an Orphan
|
|
January 28, 2014, 12:55:34 AM |
|
Always love these reports!
|
Mining Both Bitcoin and Litecoin.
|
|
|
Sonny
|
|
January 28, 2014, 01:08:59 AM |
|
I'll try their support address, but I'm not sure they'll respond to an english email out of the blue.
Discus Fish is a Chinese pool that was started by Chinese student bitcoin enthusiasts. I don't know much more about it. There's a bit of information about the relationship between Discus Fish and "For Pierce and Paul" here: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/12/29Judging from that chat log, I guess they will welcome you if you show yourself as organofcorti. 20:07 wangchun if you read organofcorti's weekly report, we are "Discus Fish" (pool) and "For Pierce and Paul" (solo)
|
|
|
|
iongchun
Member
Offline
Activity: 75
Merit: 10
|
|
January 28, 2014, 05:39:34 AM |
|
Of course not, you can read from my signature Perhaps I should have written "Have you mined there?" From what I read on f2pool’s website, it is a PPS pool with 4% fee (24 BTC paid per block), payout is made once a day for miners with balance of 0.0005 BTC or more. It seems only Stratum is supported as mining protocol. I guess tx fee is kept by the pool.
Google translate tells me similar. I'll try their support address, but I'm not sure they'll respond to an english email out of the blue. Hope you have progress with it, organofcorti. I tried the pool for some time, and observe the following: 1. The pool always gives out works of difficulty 256, no matter with 333Mh/s or 33Gh/s hardware; 2. No pool statistics is available even for a registered user. I can only see user hashrate graph, miner hashrate, balance, etc.; 3. Payout is round to 0.0001, the remaining is kept in user balance. Regards, iongchun
|
Bitcoin: 1NFMpJUW7sTKmnVKj12MxhPvCvzAKQ5gUV Namecoin: N5Tnt3JyMeizsoAFAZDr7CSxjzDtPSisK8 Mining with P2Pool. Graph. Blocks.
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
January 28, 2014, 07:13:34 AM |
|
you have progress with it, organofcorti. I tried the pool for some time, and observe the following: 1. The pool always gives out works of difficulty 256, no matter with 333Mh/s or 33Gh/s hardware; 2. No pool statistics is available even for a registered user. I can only see user hashrate graph, miner hashrate, balance, etc.; 3. Payout is round to 0.0001, the remaining is kept in user balance.
Regards, iongchun
Thanks, iongchun. Were you mining long enough to get a feel for pool reliability? They replied to my email almost straight away, which was nice. No complete block history API just yet, but lots of new and interesting information!
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
January 28, 2014, 07:17:03 AM |
|
Always love these reports!
Where the hell have you been? Good to see you back here, been a while.
|
|
|
|
wknight
Legendary
Offline
Activity: 889
Merit: 1000
Bitcoin calls me an Orphan
|
|
January 28, 2014, 03:28:54 PM |
|
Always love these reports!
Where the hell have you been? Good to see you back here, been a while. Lots of projects at the day to day job . Things are starting to free up a bit more. I am glad you stuck with the pool reports!
|
Mining Both Bitcoin and Litecoin.
|
|
|
bitcoinmining
|
|
January 28, 2014, 07:50:53 PM |
|
mining, statistics very good gains going well're always the case continued
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
January 28, 2014, 08:36:07 PM |
|
mining, statistics very good gains going well're always the case continued
Google translate did a poor job there. Would you mind posting again?
|
|
|
|
iongchun
Member
Offline
Activity: 75
Merit: 10
|
|
January 30, 2014, 12:00:11 AM |
|
Thanks, iongchun. Were you mining long enough to get a feel for pool reliability?
I just tried it for nearly 2 days with 33Gh/s, 20min miner hash rate floats between 25 to 38Ghz/s, I guess it is due to high difficulty (256). Reject rate is about 1.2%, and pool statistics from bfgminer: Unable to get work from server occasions: 2 I think this pool could be considered stable. They replied to my email almost straight away, which was nice. No complete block history API just yet, but lots of new and interesting information!
Look forward to your report for next week
|
Bitcoin: 1NFMpJUW7sTKmnVKj12MxhPvCvzAKQ5gUV Namecoin: N5Tnt3JyMeizsoAFAZDr7CSxjzDtPSisK8 Mining with P2Pool. Graph. Blocks.
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
February 02, 2014, 01:33:20 PM |
|
February 2nd 2014 Weekly Hashrate Contributor and Network StatisticsOther Weekly Hashrate Contributor and Network Statistics postsWelcome, miners. Changelog: Changed the smoothing method for figure 3. Added new table and chart explanations, placed immediately prior to the table / chart. Usual pools missing from results: I haven't rebuilt this part yet - still TBA. Errors: I haven't found any - please tell me if you find something. 0. Still more work to go. I forgot to write a simple script checking for hashrate contributors that have contributed to the network recently but not for the current week, that is "Usual pools missing from results". Simple enough to do, No excuses except that I ran out of time. I'm also unsure about how to proceed with the "orphaned blocks" chart. Initially I wanted to do a cumulative or moving average of the percentage of orphaned blocks, but from experience I know that readers see non-existent trends in these sort of plots (moving average charts do not consist of independent data and so cannot show trends) and all sorts of confusion results. Instead I've decided to do a kernel smoothed density plot. I haven't yet decided whether to plot the data separately or on one chart, or stacked or something else. Hopefully I'll come up with something soon. Once the data reporting is just as I want it, I'll be able to start commenting on the data again. Explanation of the tables and charts. Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table. "Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above. Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round. A much more accurate estimate of the hashrate, confidence intervals are unnecessary. Orphan races lost, and percentage of solved blocks that were not added to the blockchain. "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares. CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks. Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one million Difficulty 1 shares (or one thousand difficulty 1000 shares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block. Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface can not be included. Figure 3: Percentage of blocks solved each week for the current top ten contributors. Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data. As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong. You can view this weeks charts at http://organofcorti.blogspot.com/2014/02/february-2nd-2014-weekly-hashrate.htmlYou can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
February 09, 2014, 08:05:30 AM |
|
February 9th 2014 Weekly Hashrate Contributor and Network StatisticsOther Weekly Hashrate Contributor and Network Statistics postsWelcome, miners. Changelog: Changed the hashrate scaling for figure 6 to Thps. Improved the generation address ownership algorithm, resulting in slightly fewer "Unknown" blocks. Usual pools missing from results: I haven't rebuilt this part yet - still TBA. Errors: I still haven't found any. 0. No orphaned block charts yet I think I've found the best way to chart orphaned blocks, I just need time to do it. Hopefully I'll find time this week or the next. 1. The network hashrate continues to increase, as do unknown contributors Another 1226 blocks solved this week, 218 more than expected. Of these, 104 blocks are from unknown contributors. If you turn to table 3, you can see that one of the generation addresses has now been assigned a total of 24 blocks, five in this week alone. Interestingly, none of the block reward has moved from this address yet. It seems there are some new cloud-hashers around. Maybe KNC has gotten their data centre going already? That's all I have time for this week. Enjoy the chartporn, and see if you can find out to whom some of the richer unknown generation addresses belong. Explanation of the tables and charts. Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round. A much more accurate estimate of the hashrate, confidence intervals are unnecessary. Orphan races lost, and percentage of solved blocks that were not added to the blockchain. "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares. CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks. Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one million Difficulty 1 shares (or one thousand difficulty 1000 shares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block. Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface can not be included. Figure 3: Percentage of blocks solved each week for the current top ten contributors. Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data. Figure 5: Pool "luck" (valid + invalid solved blocks) The orange dots are the usual accepted shares / expected shares (equivalently, shares per round / network Difficulty). The background colours are accepted shares / expected shares confidence intervals for the number of blocks solved for the week. The greater the number of blocks solved (the higher the percentage of the network) the narrower the bounds. The "luck" data points should be outside the upper or lower boundaries only rarely. Many data points outside this range indicate unusual and unlikely "luck". Data only goes back for the last twelve months at most - any more data points than this becomes hard to read, and recent data is most important. Note that all solved blocks are used, otherwise the data would no longer be Erlang distributed and a CDF could not be calculated. As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong. You can view all of this weeks charts at http://organofcorti.blogspot.com.au/2014/02/february-9th-2014-weekly-hashrate.htmlYou can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
February 19, 2014, 04:29:44 AM |
|
February 16th 2014 Weekly Hashrate Contributor and Network StatisticsOther Weekly Hashrate Contributor and Network Statistics postsOther weekly pool and network statistics posts Welcome, miners. Changelog: Added Figure 7: Orphaned blocks. Usual pools missing from results: I haven't rebuilt this part yet - still TBA. Errors: According to my data, Polmine has only had one orphaned block in the last 700. This may be a mistake. 0. Orphaned block chart, for the first time. This post is a bit late as I had some problems getting the chart and the data right. I'm not going to make any more comments than that tonight, but I do have some interesting things that I need to post and I hope I get time to do that later this week. Explanation of the tables and charts. Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table. "Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above. Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round. A much more accurate estimate of the hashrate, confidence intervals are unnecessary. Orphan races lost, and percentage of solved blocks that were not added to the blockchain. "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares. CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks. Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one million Difficulty 1 shares (or one thousand difficulty 1000 shares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block. Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface can not be included. Figure 3: Percentage of blocks solved each week for the current top ten contributors. Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data. Figure 7: Density of orphaned blocks This chart shows the density of orphaned blocks per pool, as a function of blocks solved by that pool. The fringe indicates the actual occurences of of the orphaned blocks, and the colour of the line and fringe indicate the approximate date. Some orphan data may be missing from Polmine. The rest seem to be correct. As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong. You can view all of this weeks charts at http://organofcorti.blogspot.com.au/2014/02/february-16th-2014-weekly-hashrate.htmlYou can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
February 24, 2014, 07:53:41 AM |
|
This should help miners get a better idea of the hashrates at for pools at which they might want to mine. I'll be updating this weekly here, and also in the thread so there's a history. If you'd like anything else, let me know. If your pool isn't here and you'd like it to be, PM me with a link to a block history with round lengths and either solve times to the nearest second or a timestamp. February 23rd 2014 Weekly Hashrate Contributor and Network StatisticsOther Weekly Hashrate Contributor and Network Statistics postsWelcome, miners. Changelog: NA. Errors: Nil 0. Welcome back Ozcoin! Ozcoin hooks a block this week and returns to the weekly stats for the first time in a while. It'll have been a big payday for Ozcoin miners! 1. Unknown generation addresses. The unknown part of the network hashrate was 1 to 2 % from July 2013 to the start of this year. Since then, it's increased to about 8% of the network. I don't care if this is all solominers, but it could be that some large hashrate contributor is attempting to hide some of their hashes - which might mean they're approaching 51% of the network. Most of my time is spent trying to find associations between the unknown generation addresses and known addresses - if you think you know something that might help, please post a comment. Explanation of the tables and charts. Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table. "Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above. Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round. A much more accurate estimate of the hashrate, confidence intervals are unnecessary. Orphan races lost, and percentage of solved blocks that were not added to the blockchain. "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares. CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks. Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block. Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included. Figure 3: Percentage of blocks solved each week for the current top ten contributors. Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data. You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
March 03, 2014, 01:18:43 AM |
|
March 2nd 2014 Weekly Hashrate Contributor and Network StatisticsOther Weekly Hashrate Contributor and Network Statistics postsWelcome, miners. Changelog: AntPool and KoiSystems identified from coinbase signature and generation addresses and have been added to the weekly statistics. Errors: Data from Polmine and Ozcoin seem unlikely. 0. KNC goes solo As I was just about to post this I found out that KNC Mining had left Eligius and gone back to running their own pool. I didn't have time to add them in, but I will for the next post. Does anyone have the generation address used in November when they were first running their own pool? 1. Eligius overtakes BTCGuild However with KNC gone, I wonder if they'll still be in second place next week? 2. Unknown generation addresses. I'm still working on this, but haven't had much spare time lately. Explanation of the tables and charts. Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table. "Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above. Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round. A much more accurate estimate of the hashrate, confidence intervals are unnecessary. Orphan races lost, and percentage of solved blocks that were not added to the blockchain. "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares. CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks. Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block. Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included. Figure 3: Percentage of blocks solved each week for the current top ten contributors. Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data. You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
|
March 03, 2014, 03:27:20 PM |
|
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
March 04, 2014, 06:46:11 AM |
|
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though.
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
|
March 05, 2014, 01:27:49 AM |
|
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though. Was thinking about it some too & I guess I could be wrong anyway..... re: bitminter + eclipseMC combined seem to get about 1/4th as many blocks as ghash.io? so it could be similar proportionately
|
|
|
|
organofcorti (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
March 05, 2014, 02:14:17 AM |
|
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though. Was thinking about it some too & I guess I could be wrong anyway..... re: bitminter + eclipseMC combined seem to get about 1/4th as many blocks as ghash.io? so it could be similar proportionately I'm at work so I can't link to it, but my most recent weekly stats posts have a chart of orphaned block densities kernel smoothed against number of blocks solved. his makes it possible to compare different pools. Have a look if you get time.
|
|
|
|
cyrpi4
Member
Offline
Activity: 85
Merit: 10
|
|
March 05, 2014, 04:55:26 PM |
|
Wow! Ozxoin has done great! zvs , what will be your next forecast?
|
Donations: 2235fa09-d5b3-4d5d-9b28-d1281abc1ccb
|
|
|
|