I'm not interested what figures draws one or another pool.
You posted figures about pool and not interested now?
I already told you that by the PPLNS distribution policy you would get less reward at first mining day. Hope I explained all.
Thanks.
I'm mining on Coinotron from 4 February. They have the same payment PPLNS, from the first day they almost match the payment calculator for +/- 2-3%. You have two days (I test with UTC23:00 31.03 - 23:00 02.04) - less than 14% on average. and you may be scam. it is very similar to that.
I'm mining on Coinotron from 4 February. They have the same payment PPLNS, from the first day they almost match the payment calculator for +/- 2-3%. You have two days (I test with UTC23:00 31.03 - 23:00 02.04) - less than 14% on average. and you may be scam. it is very similar to that.
You told us that you mined one day at first and now you are saying you mined two days. You already told us goodbye, wished us good luck, but you were still mining? What is your intention? To attack pool? saying SCAM without any proof?
And even if you really did that, you just hopped in and out within three days, so PPLNS policy worked against you two times because you didn't mine continually. Keep in mind that PPLNS is based on block round, this policy affects drastically on small pools more. If one pool finds 60 blocks and the other pool finds 600 blocks a day, PPLNS effect is nearly 10 times bigger for smaller pools.
We've been running pool service for more than two years. We had many troubles, difficulties to overcome like DDoS attack, fake shares, attack from other pools, hard fork issues, etc. We are not pool operators like opening one day and closing next week, stealing coins.
We compensated when coin hard fork issue happened. It happened on Digibyte, Vertcoin, and Feathercoin. We also compensated when network connection port had some problem. It happened on Maxcoin. You may find our compensation history from each pool's news section or bitcointalk's thread. We gained trust by running pools for a long time. This can't be done one day, needed several months.
Pool efficiency may vary much, and we can't guarantee that technically. But it's totally different thing to say that we are SCAM.
There's quite many miners on ethereum pool currently. Many of them would have left if they see their mining reward is much smaller than other pools. Like you, most of them are from other ethereum pools, so they know average reward they should get. Actually I received many messages that they started to get more reward than before.
Tell me your id then. I'll check if there were any mining problem with your account.
I'm mining on Coinotron from 4 February. They have the same payment PPLNS, from the first day they almost match the payment calculator for +/- 2-3%. You have two days (I test with UTC23:00 31.03 - 23:00 02.04) - less than 14% on average. and you may be scam. it is very similar to that.
You told us that you mined one day at first and now you are saying you mined two days. You already told us goodbye, wished us good luck, but you were still mining? ...bla-bla-bla-.... ----------cut-------------
Can not you read? my first post - 31.03,
last today! 02.04
It took two days The first observations were after the first day. In the last post I wrote already about two days, that to understand? or are you stupid?
I'm not interested what figures draws one or another pool.
You posted figures about pool and not interested now?
I already told you that by the PPLNS distribution policy you would get less reward at first mining day. Hope I explained all.
Thanks.
I'm mining on Coinotron from 4 February. They have the same payment PPLNS, from the first day they almost match the payment calculator for +/- 2-3%. You have two days (I test with UTC23:00 31.03 - 23:00 02.04) - less than 14% on average. and you may be scam. it is very similar to that.
miningpoolhub is not a scam, but rather you are a troll... too bad this forum doesn't have killfiles. :-(
U follower-bot miningpoolhub? welcome to the real world, baby. it is a real scam, steal 14% of the resources a day.
It took two days The first observations were after the first day. In the last post I wrote already about two days, that to understand? or are you stupid?
because my statistics are based on my observations. On Coinotron I'm mining has on average 14% higher in 24 hours. And the data that I have given above, it is only confirmed.
I will not work in your minig pool, and do not advise others. Good luck!
You already finished testing two pools on April 1st, as you said, based on your observation. 24 hours. And you told us that you will be not mining at miningpoolhub. is it right?
So no more minig after April 1st. You even left "Good luck" and left pool.
Now you came again and saying that you were mining after that, even at April 2nd.
It took two days The first observations were after the first day. In the last post I wrote already about two days, that to understand? or are you stupid?
because my statistics are based on my observations. On Coinotron I'm mining has on average 14% higher in 24 hours. And the data that I have given above, it is only confirmed.
I will not work in your minig pool, and do not advise others. Good luck!
You already finished testing two pools on April 1st, as you said, based on your observation. 24 hours. And you told us that you will be not mining at miningpoolhub. is it right?
So no more minig after April 1st. You even left "Good luck" and left pool.
Now you came again and saying that you were mining after that, even at April 2nd.
Nothing is broken. Just a period of bad luck probably.
--
I've been doing a hash-per-hash comparison of ethpool and MPH profits for a bit now. Can confirm the results are staying quite steady. In the time it took to find a block and get 4.95Eth (+ maybe 1/20 odds of an uncle payout), I earned a bit over 6Eth on MPH. Pool seems to be running quite smoothly.
Nothing is broken. Just a period of bad luck probably.
--
I've been doing a hash-per-hash comparison of ethpool and MPH profits for a bit now. Can confirm the results are staying quite steady. In the time it took to find a block and get 4.95Eth (+ maybe 1/20 odds of an uncle payout), I earned a bit over 6Eth on MPH. Pool seems to be running quite smoothly.
Actually we have been doing mining simulation for better reward on our work pc. We will apply some method to maximize the mining potential soon. Hope you satisfied more then.
The PPLNS and average lines are slightly over 100% luck, so mining returns should be above normal right now. However when I look at the pool stats it says I'm at 130.767MH/s and 1.684 eth/day.
With a 14s block time there are about 6172 blocks mined per day, * 5 eth reward per block = 30860 eth mined per day. The network hash rate is 1859GH/s, so 130.8 MH is 7e-5 of that, which should give 2.17 eth/day.
Unlike dwarf, mph doesn't seem to show how much was mined in the last 24hrs, making it much harder confirm that I'm getting what I expect. I'd like to see that (24hr earnings) added to the dashboard stats, and I'd like to see the block graph changed from block number to hours/days (like antpool).
Thank you for your suggestion. We will implement many things to the dashboard and block stats.
I would like to show some workaround methods.
When we track some miners, most of them got x1.2~1.4 to their estimated ETH/Day. ETH/Day was not that important at first since small pool flunctuates much, but we have heard many suggestions about it. Maybe we would have to tweak this ETH/Day thing to more accurate.
Actually we changed statistic's block time to 12s few days ago, and reverted back 14s now. (It just affects statistic's Gen Est.) The reason why we changed to 12s few days ago is that I just wanted to see accurate integer number for Gen Est column. (12s is exactly divisable for time things while 14s is not) Also, ethereum is heading to 12s target time, and would achieve in near future as well. https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
"Last 24 Hours" row, "Gen Est." column is now showing 6171 for 24 hours which is based on 14s. (Actually it's 6171.4285714286) Next column is showing 73 for Found blocks within last 24 hours currently. Maybe these numbers are what you wanted to see?
You can also track your earnings from Transactions. Set Type as 'Credit' and you would see latest earnings. I know this is not easy, because you have to add all credits upto some time period.
These are just workarounds. We are not saying that you stick to this method. We will implement, improve many things.
Changing block stats as you mentioned seems good, but there's some other miners who prefer current style. We will consider to satisfy miners as many as possible.
@bitcanuck You're getting a bunch of numbers backwards, and some outright wrong. e.g. <100% means a block was found before expected; >100% means after.
Global network hashrate is a very VERY serious approximation too. There's no possible way to know what it is really. Pool hashrate is similarly an approximation.
As for "mined blocks withheld", there's no benefit to the miner doing that, but there's also no way to prevent it with any pool.
@bitcanuck huh? I definitely showed you one of your major errors, you mixed up luck % entirely, getting it backwards.
I get that you used blocks per day, but you're using pool estimated hashrate... which as I said is even more of an approximation then entire network hashrate (because it's averaged from a smaller set).
You mentioned f2pool... they are paying ~0.01609824ETH / Mhash/s / Day right now. So 200MH/s would earn 3.2Eth. Now how about EthPool - you'll find a block with ~28T credits right now. 28T credits would have taken 200MH a bit over 1.5 days, so 5/1.5 = ~3.3Eth/day (presuming you don't get lucky and hit an uncle too). 200MH on MPH over the last 24hr (based on stated pool hashrate) would be 372Eth * 200 / 21251 = 3.5Eth.
MPH in all my testing and math has come out on top for profits. If there is a fake share or block hiding attack going on, it's happening to every other pool too. And something like that wouldn't effect f2pool's PPS scheme, so, it's incredibly unlikely there is any kind of attack happening against MPH.
@bitcanuck Sigh... you seem like you don't want to understand at this point. I explained it pretty clearly - you got luck backwards, you used 90% to mean 10% below expected when luck on MPH means the opposite - 90% means blocks.were found on average 10% faster then expected.
And wtf are you talking about? Over the last 24hr MPH earned 372Eth. Take that, multiply by 200MH/s and divide by pool hashrate of 21GH/s and you get 3.5Eth.
@bitcanuck Why are you looking at those stats... ? That Eth/day is obviously an estimate based on 100% luck (which the pool is consistently doing better then) and therefore nowhere near accurate. It's definitely not a reflection of the last 24hours. Case in point, that top miner at this moment is listed as 4,293,561MH/s and 60.236Eth/day...
Look at real stats and you'll get the same numbers as me.
On the pool page, look at Pool Hash Rate (albeit that's an estimate too) On the blocks page, look at Last 24 hours earned
If you want to calculate EXACTLY, then use the blocks page and calculate based on shares. Anything else is FUD.
I read that blog post a long time ago. It has nothing to do with mining returns today, which is what I'm concerned with.
We just tried to say that why we changed 14s -> 12s -> 14s for ethereum's block time, thinking that maybe some miners would be curious about why Gen Est. number is changing. Yeah, it doesn't affect mining returns.
to confirm that you are not mistakenly accepting fake shares or have miners that are holding back some of the blocks they mine.
We can say that we totally block fake shares. We check every share miner insertion, calculate each difficulty level and reject if it doesn't satisfy. We have some special policy that send miners "accepted" for even stale shares. Stale shares can be used for DDoS like attacks, and even for normal miners it makes performance decrease on their proxy. (Proxy programs try to resend invalid shares when we reject them, and it harms their performance) Also we check if shares are duplicated.
"Holding back some of the blocks they mine" is actually impossible. What we generate and distribute data actually includes pool's wallet address. Pool sends each miners three data. "headerHash", "seedHash", "difficulty to satisfy". The headerHash is generated with pool wallet address, previous block hash, transactions hash things. So, even when miner get some block finding solution, they can't generate it from their wallet because their wallet has different headerHash to generate. Only pool wallet can generate it.
One more thing. We generated wallet address for each server regions, they are all different each other. When we use same wallet address for every region server, then miner would get some chance to insert same shares to asia, europe, us-east, and us-east-backup server. So miner would get x4 payout than normal. This kind of fake share was impossible for bitcoin like coins, because pool assign every miner with unique extranonce1 value. But there's no way to assign miner their unique id, this type of fake share insertion is possible for ethereum. You would find some pools out there, having more server regions than server wallets. I didn't try their servers with this fake method but they are vulnerable to this kind of fake shares if they didn't do some kind of cross checking. I'm sure they didn't make that kind of fake share checking because it's very very inefficient. The only way to block fake share among different servers is separating wallet addresses.
Maybe these are quite surprising thing at first. We didn't tell about stale share policy and wallet generation for each region because this kind of info can harm other pools. These are all fake shares issues we concerned about, we block all of them, so don't worry about it.
In the last 24hrs there were 77 blocks found, and with a pool hash rate of 26.356, with 100% luck the pool should earn 26.356/1973.5 = 1.3355% of the 6172 blocks per day, or 82.43 blocks. So the pool luck was 93.4%. The block stats page says 85.22%, which maybe means a 8.75% uncle rate? The weekly stats are slightly worse and the last month stats are slightly better. The probability of this being unusually bad luck is extremely low, so I think the pool is being hacked by some means (fake shares, mined blocks withheld, ...)
We already discussed about pool total hashrate some day ago. We bump about x1.12 to their total hashrate to match the numbers from their miner program showing. I think you already read the inefficiency of short block time from the Vitalik's blog post. There's many inefficient points, like network, cpu processing, miner job resetting, and these numbers affects real earnings much. Don't take inefficiency as little. 12s is quite short time. If there's no inefficient points, there must be any uncle blocks.
Variance is another thing to discuss, and it really affects much at small pool. If other pool's total hashrate is x20 than mph, then that pool would get much more stabilized payout. The stabilized means earning per hour/day is constant.
Let me show you an example. MPH occasionally don't find a block an whole hour even these days. Then MPH's bad luck affects 60/1440 of daily income. (1440 came from 60 minutes * 24 hours) But x20 pool's same bad luck percentage means, 60/20 minutes of no block, which only means 3 minutes of no block. so it affects 3/1440 of daily income.
Miners will measure their profits daily, so these numbers affects much. This is the variance we say about, it can be 10% or more.
Pool stat is based on their own configurations. So each pool can't be compared by their stats. We use x1.12 bump for error correction, but others would not use it.
I think you'd better try f2pool, or other pools too with hash to hash comparison. This is the only way to compare pools. Don't trust numbers at statistics. That numbers are not based on same criteria between pools.
@miningpoolhub Thanks for the details, though it would've been a lot better if you had made the info public on your website (especially the part about grossing up hashrate by 12%). I had suspected the pool stats were showing higher numbers than I was actually getting, but given the variability of mining in general and specifically the variability in my mining rate due to testing new cards etc., I didn't have enough data to confirm it.
As I've said before, showing the amount of eth earned in the last 24h like dwarf does would help a lot with comparisons between pools.
I was a bit afraid when we publish that we bump 12% of their reported hashrate because other pools don't tell this kind of info. This is just error correctness of difficulty -> hashrate formula for short block time coins.
12% is not static and can be adjusted when ethereum block time get shorter. This value is just measured by our real hardware. As this is just error correctness factor to reflect miner programs hashrate to pools, it doesn't affect mining rewards. Only frontend hashrate numbers are affected. I think this type of margin made you think of fake share things.
Also, some pools don't use this bump, but use submitHashrate data which is hashrate reported exactly from ethminer. So other pool operator would not agree about bumping error correctness as well. I hope you understand this point. There's so many methods to implement pool and every configuration affects each other. Pools are not same. Their statistics are not same as well.
We will implement earned eth for last 24h soon. Thanks.
I would bet most of the reason you need to bump 12% to get a comparable hashrate representation is because ethminer has a lot of inefficiencies, and you lose quite a bit of hashrate due to GPU load drop-offs and lost work potential.
I would bet most of the reason you need to bump 12% to get a comparable hashrate representation is because ethminer has a lot of inefficiencies, and you lose quite a bit of hashrate due to GPU load drop-offs and lost work potential.
I agree. It would be better if ethminer shows 1 minute average hashrate. Current ethminer don't seem to consider mining reset delay which occurs every 14 seconds.
Switched to MPH/Ethereum today, but I have too much GPU load drops, too much "Worker stopping xxxx ms / GPU incorrect result"-blah-blah and too less mining here. What can be wrong? Before at Coinotron a hadn´t such big problems! Support please! With no solution, I have to go back to Coinotron again in a few hours.
Thank you for the hint. Before with Cointron, I also had a steady 100% GPU load. But I trying out CPP-Eth now with MHP. I´m from Germany, so I selected their European server.
I decided to stay with MPH without touching my rigs in order to see how much I get. I have 140-145MH/s of gear (R9 280x, 7950, and 5x R9 380) using dwarf's eth-proxy mod. Yesterday around 23:00 UTC I got a payment of 1.09 eth after mining for 12h17m, and I got a payout of 1.08 eth 8h45m later. That's an "average" of 2.5 eth/day so far. That's close enough to what I was expecting to keep me on mph for another day or two to get some more data on payout rates.
Good to hear that you try pool to pool comparison. We had bad luck yesterday and good luck few hours ago. It seems like hard to point the average reward on these situation.
I hope you to try more than a week. Thanks anyway.
Comments
You posted figures about pool and not interested now?
I already told you that by the PPLNS distribution policy
you would get less reward at first mining day.
Hope I explained all.
Thanks.
and you may be scam. it is very similar to that.
You told us that you mined one day at first and now you are saying you mined two days.
You already told us goodbye, wished us good luck, but you were still mining?
What is your intention? To attack pool? saying SCAM without any proof?
And even if you really did that, you just hopped in and out within three days, so PPLNS policy worked against you two times because you didn't mine continually.
Keep in mind that PPLNS is based on block round, this policy affects drastically on small pools more.
If one pool finds 60 blocks and the other pool finds 600 blocks a day, PPLNS effect is nearly 10 times bigger for smaller pools.
We've been running pool service for more than two years.
We had many troubles, difficulties to overcome like DDoS attack, fake shares, attack from other pools, hard fork issues, etc.
We are not pool operators like opening one day and closing next week, stealing coins.
We compensated when coin hard fork issue happened. It happened on Digibyte, Vertcoin, and Feathercoin.
We also compensated when network connection port had some problem. It happened on Maxcoin.
You may find our compensation history from each pool's news section or bitcointalk's thread.
We gained trust by running pools for a long time. This can't be done one day, needed several months.
Pool efficiency may vary much, and we can't guarantee that technically.
But it's totally different thing to say that we are SCAM.
There's quite many miners on ethereum pool currently. Many of them would have left if they see their mining reward is much smaller than other pools. Like you, most of them are from other ethereum pools, so they know average reward they should get.
Actually I received many messages that they started to get more reward than before.
Tell me your id then. I'll check if there were any mining problem with your account.
Thanks.
my first post - 31.03,
last today! 02.04
It took two days
The first observations were after the first day.
In the last post I wrote already about two days, that to understand?
or are you stupid?
Mentioning uncle rate doesn't mean that
"I'm mining here and uncle rate is high", but only "uncle rate is high"
You didn't say you tested two days, but you told us that you observed 24 hours.
April 1st, you wrote
You already finished testing two pools on April 1st, as you said, based on your observation. 24 hours.
And you told us that you will be not mining at miningpoolhub. is it right?
So no more minig after April 1st.
You even left "Good luck" and left pool.
Now you came again and saying that you were mining after that, even at April 2nd. And you are saying
"I mined for two days and it can't be affected by PPLNS, I think this pool is SCAM, pool operator is stupid"
31 started. April 1 - passed day, April 2 - passed 2.
what's wrong?
https://miningpoolhub.com/index.php?page=api&action=getuserstatus&api_key=....
I had a feedback script which would restart any broken miners if the hashrate dropped
You can get your api key at
https://miningpoolhub.com/?page=account&action=edit
and query user status like this.
https://ethereum.miningpoolhub.com/index.php?page=api&action=getuserstatus&api_key= .... api key...
Host name must be ethereum.miningpoolhub.com since this is target coin you want to monitor.
Actually we provide worker monitoring service as well.
You can turn on/off for each worker and you will get notified when some worker don't submit shares for certain amount of time.
https://ethereum.miningpoolhub.com/index.php?page=account&action=workers
Thanks.
I couldn't distinguish normal miner and troll at that time.
Thank you. Appreciated.
Ah...
Only displaying 100% at the middle of chart, and simple line looks quite good.
I agree that our graph seems a bit complex to understand.
We will consider it to improve it.
Thank you again.
Last Hour 300 0 0 0 0 0 0 0.00% 0 0.00%
--
I've been doing a hash-per-hash comparison of ethpool and MPH profits for a bit now. Can confirm the results are staying quite steady. In the time it took to find a block and get 4.95Eth (+ maybe 1/20 odds of an uncle payout), I earned a bit over 6Eth on MPH. Pool seems to be running quite smoothly.
You're welcome.
It's not broken. Mining Pool Hub is still small, sometimes pool can't find block for an hour.
Great to hear that MPH gave you more.
Actually we have been doing mining simulation for better reward on our work pc.
We will apply some method to maximize the mining potential soon.
Hope you satisfied more then.
Thanks.
You can now explore each page on Transactions with filter set.
When you click next page arrow, filter got reset every time before this fix.
Now it's fixed.
Thanks.
Thank you for your suggestion.
We will implement many things to the dashboard and block stats.
I would like to show some workaround methods.
When we track some miners, most of them got x1.2~1.4 to their estimated ETH/Day.
ETH/Day was not that important at first since small pool flunctuates much, but we have heard many suggestions about it.
Maybe we would have to tweak this ETH/Day thing to more accurate.
Actually we changed statistic's block time to 12s few days ago, and reverted back 14s now.
(It just affects statistic's Gen Est.)
The reason why we changed to 12s few days ago is that I just wanted to see accurate integer number for Gen Est column. (12s is exactly divisable for time things while 14s is not)
Also, ethereum is heading to 12s target time, and would achieve in near future as well.
https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
"Last 24 Hours" row, "Gen Est." column is now showing 6171 for 24 hours which is based on 14s.
(Actually it's 6171.4285714286)
Next column is showing 73 for Found blocks within last 24 hours currently.
Maybe these numbers are what you wanted to see?
You can also track your earnings from Transactions.
Set Type as 'Credit' and you would see latest earnings. I know this is not easy, because you have to add all credits upto some time period.
These are just workarounds. We are not saying that you stick to this method.
We will implement, improve many things.
Changing block stats as you mentioned seems good, but there's some other miners who prefer current style. We will consider to satisfy miners as many as possible.
Thank you for your feedback again.
Pool stats are here https://ethereum.miningpoolhub.com/index.php?page=statistics&action=pool
e.g. <100% means a block was found before expected; >100% means after.
Global network hashrate is a very VERY serious approximation too. There's no possible way to know what it is really. Pool hashrate is similarly an approximation.
As for "mined blocks withheld", there's no benefit to the miner doing that, but there's also no way to prevent it with any pool.
I get that you used blocks per day, but you're using pool estimated hashrate... which as I said is even more of an approximation then entire network hashrate (because it's averaged from a smaller set).
You mentioned f2pool... they are paying ~0.01609824ETH / Mhash/s / Day right now. So 200MH/s would earn 3.2Eth. Now how about EthPool - you'll find a block with ~28T credits right now. 28T credits would have taken 200MH a bit over 1.5 days, so 5/1.5 = ~3.3Eth/day (presuming you don't get lucky and hit an uncle too). 200MH on MPH over the last 24hr (based on stated pool hashrate) would be 372Eth * 200 / 21251 = 3.5Eth.
MPH in all my testing and math has come out on top for profits. If there is a fake share or block hiding attack going on, it's happening to every other pool too. And something like that wouldn't effect f2pool's PPS scheme, so, it's incredibly unlikely there is any kind of attack happening against MPH.
And wtf are you talking about? Over the last 24hr MPH earned 372Eth. Take that, multiply by 200MH/s and divide by pool hashrate of 21GH/s and you get 3.5Eth.
Learn to math?
Look at real stats and you'll get the same numbers as me.
On the pool page, look at Pool Hash Rate (albeit that's an estimate too)
On the blocks page, look at Last 24 hours earned
If you want to calculate EXACTLY, then use the blocks page and calculate based on shares. Anything else is FUD.
Thank you for discussing pool block percent, and luck.
We consider it much too. Not only luck, we consider the real payout for each miners.
We just tried to say that why we changed 14s -> 12s -> 14s for ethereum's block time, thinking that maybe some miners would be curious about why Gen Est. number is changing. Yeah, it doesn't affect mining returns. We can say that we totally block fake shares.
We check every share miner insertion, calculate each difficulty level and reject if it doesn't satisfy.
We have some special policy that send miners "accepted" for even stale shares. Stale shares can be used for DDoS like attacks, and even for normal miners it makes performance decrease on their proxy.
(Proxy programs try to resend invalid shares when we reject them, and it harms their performance)
Also we check if shares are duplicated.
"Holding back some of the blocks they mine" is actually impossible. What we generate and distribute data actually includes pool's wallet address. Pool sends each miners three data. "headerHash", "seedHash", "difficulty to satisfy". The headerHash is generated with pool wallet address, previous block hash, transactions hash things. So, even when miner get some block finding solution, they can't generate it from their wallet because their wallet has different headerHash to generate. Only pool wallet can generate it.
One more thing. We generated wallet address for each server regions, they are all different each other.
When we use same wallet address for every region server, then miner would get some chance to insert same shares to asia, europe, us-east, and us-east-backup server.
So miner would get x4 payout than normal. This kind of fake share was impossible for bitcoin like coins, because pool assign every miner with unique extranonce1 value. But there's no way to assign miner their unique id, this type of fake share insertion is possible for ethereum.
You would find some pools out there, having more server regions than server wallets. I didn't try their servers with this fake method but they are vulnerable to this kind of fake shares if they didn't do some kind of cross checking. I'm sure they didn't make that kind of fake share checking because it's very very inefficient. The only way to block fake share among different servers is separating wallet addresses.
Maybe these are quite surprising thing at first. We didn't tell about stale share policy and wallet generation for each region because this kind of info can harm other pools.
These are all fake shares issues we concerned about, we block all of them, so don't worry about it.
We already discussed about pool total hashrate some day ago. We bump about x1.12 to their total hashrate to match the numbers from their miner program showing.
I think you already read the inefficiency of short block time from the Vitalik's blog post. There's many inefficient points, like network, cpu processing, miner job resetting, and these numbers affects real earnings much. Don't take inefficiency as little. 12s is quite short time. If there's no inefficient points, there must be any uncle blocks.
Variance is another thing to discuss, and it really affects much at small pool.
If other pool's total hashrate is x20 than mph, then that pool would get much more stabilized payout.
The stabilized means earning per hour/day is constant.
Let me show you an example.
MPH occasionally don't find a block an whole hour even these days. Then MPH's bad luck affects 60/1440 of daily income. (1440 came from 60 minutes * 24 hours)
But x20 pool's same bad luck percentage means, 60/20 minutes of no block, which only means 3 minutes of no block. so it affects 3/1440 of daily income.
Miners will measure their profits daily, so these numbers affects much. This is the variance we say about, it can be 10% or more.
Pool stat is based on their own configurations. So each pool can't be compared by their stats.
We use x1.12 bump for error correction, but others would not use it.
I think you'd better try f2pool, or other pools too with hash to hash comparison.
This is the only way to compare pools.
Don't trust numbers at statistics. That numbers are not based on same criteria between pools.
I was a bit afraid when we publish that we bump 12% of their reported hashrate because other pools don't tell this kind of info. This is just error correctness of difficulty -> hashrate formula for short block time coins.
12% is not static and can be adjusted when ethereum block time get shorter. This value is just measured by our real hardware. As this is just error correctness factor to reflect miner programs hashrate to pools, it doesn't affect mining rewards. Only frontend hashrate numbers are affected.
I think this type of margin made you think of fake share things.
Also, some pools don't use this bump, but use submitHashrate data which is hashrate reported exactly from ethminer. So other pool operator would not agree about bumping error correctness as well. I hope you understand this point. There's so many methods to implement pool and every configuration affects each other. Pools are not same. Their statistics are not same as well.
We will implement earned eth for last 24h soon.
Thanks.
I agree. It would be better if ethminer shows 1 minute average hashrate.
Current ethminer don't seem to consider mining reset delay which occurs every 14 seconds.
Settings
Ethproxy
mining_proxy.exe -o europe1.ethereum.miningpoolhub.com -p 20535
Ehtminer
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 99
ethminer.exe -G -F http://localhost:8332/myNick.myWorker --opencl-device 0 --opencl-platform 1 --farm-recheck 400 --cl-local-work 256 --cl-global-work 16384
Good to hear that you try pool to pool comparison.
We had bad luck yesterday and good luck few hours ago. It seems like hard to point the average reward on these situation.
I hope you to try more than a week.
Thanks anyway.