Topic: [ANNC] Mainframe MC moves to PPLNS reward system (Read 4128 times)
Locking this thread until people pull their heads out of their asses.
So Vladimir, what happened to the 9000 BTC wallet of donated money?
Did you spread the wealth across the many a humble miners?
Did you spread the wealth across the many a humble miners?
You are one confused or conflicted dude....You are a man without a side in this argument.
I am squarely on the side that is not full of nonsense!hear hear! *starts gibbering*
You are one confused or conflicted dude....You are a man without a side in this argument.
I am squarely on the side that is not full of nonsense! Enemy of your enemy is you friend. Since hoppers hate me so much, ethical miners really should take notice. lol
We dont hate you at all, you seem like a nice guy.
However, your mining contracts make me laugh out super loud. I guess thats another chapter of the story
Look at your ethical business approach on price per gh it kind of shows what type of businessman you are, definitely putting yourself first at all times.
Quote
Don't provide me your proof. I don't care either way. Provide your non-Vladimir 24/7 miners the proof. Or was it only Vladimir that saw an erosion of income.
If Vladimir saw an erosion, then they all would have. Apparently you are too simple minded to realize how something as simple as proportional payout works.
Quote
I still say that you are stealing blocks and declaring valid shares invalid but I won't share my proof with you because I'm officially done conversing with you at this level. I don't need to justify my certitude that you are cheating other miners for the sole benefit of Vladimir who is splitting his earning with you, a cheater.
cool story, bro!
Mainframe Mining Cooperative OFFICIAL NOTICE:
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
We aren't referring to your pools luck or speed, etc. You are performing poorly as far as your lazy miners, er I mean 24/7 miners, are concerned. Since it's clearly a matter of Vladimir making all the money and nobody else making anything, you took the opportunity of the 2 hopper myth to change your payout scheme. Please provide your evidence that you had 2 hoppers. Also please define what identified these 2 people as "hoppers".
After carefully monitoring the situation I observed that AnnihailaT is stealing blocks and declaring valid shares as stales to cheat the non-Vladimir 24/7 miners.
It's easy to say anything. Harder to prove.
Im officially done conversing with you at this level and will provide you no such proof. I need not justify the implementation of a cheat proof reward system to a cheater.
Don't provide me your proof. I don't care either way. Provide your non-Vladimir 24/7 miners the proof. Or was it only Vladimir that saw an erosion of income.
I still say that you are stealing blocks and declaring valid shares invalid but I won't share my proof with you because I'm officially done conversing with you at this level. I don't need to justify my certitude that you are cheating other miners for the sole benefit of Vladimir who is splitting his earning with you, a cheater.
Some more great work by deepceleron, the defender of the fair pool system!
Block 140749 found by pool.bitp.it:
Although this is not the best example (I actually had one block scroll by where mineco was the first to announce the block, beating the actual finding pool), we can see that pools take different amounts of time to respond. Bitp.it was almost beat in announcing their own block by mainframe. I can improve the results by tweaking like this (if I was only looking at the above results and not evaluating pool delays over many blocks):
I will test this out and see if it can completely fix false pool block designation. Of course what would be wishful thinking would be if bithopper could learn for itself the average delays it sees from each pool.
@whoever wanted an lp_penalty option:
I added it. It is lp_penalty : seconds.
Great! This feature adds X seconds to the LP receive time of the specified pool for figuring out who solved it. That means if you analyze the console log, and find one pool that is consistently faster in sending you it's LP block announce than others (especially if a pool responds to you before the one that actually found the block - causing the proxy to designate the wrong pool), then you can 'equalize' the time LPs are received by adding a delay to 'too fast' pools.I added it. It is lp_penalty : seconds.
Block 140749 found by pool.bitp.it:
[19:28:09] received lp from: bitp
[19:28:09] New Block: 5ea4b4d35340f0a60c238a721e3b0bd72453873fe6a7cec6000005f700
000000
[19:28:09] Block Owner bitp
[19:28:09] LP Call pool.bitp.it:8334/longpoll
[19:28:10] received lp from: mmf
[19:28:10] LP Call mining.mainframe.nl:8343/LP
[19:28:10] received lp from: deepbit
[19:28:10] LP Call pit.deepbit.net:8332/listenChannel
[19:28:10] received lp from: mineco
[19:28:10] LP Call mineco.in:3000/LP
[19:28:10] RPC request [getwork] submitted to polmine
[19:28:11] received lp from: bclc
[19:28:11] LP Call bitcoins.lc:8080/LP
[19:28:12] received lp from: eclipsemc
[19:28:12] LP Call pacrim.eclipsemc.com:8337/LP
[19:28:12] received lp from: arsbitcoin
[19:28:12] LP Call arsbitcoin.com:8344/LP
[19:28:14] received lp from: eligius
[19:28:14] LP Call su.mining.eligius.st:8337/LP
Although this is not the best example (I actually had one block scroll by where mineco was the first to announce the block, beating the actual finding pool), we can see that pools take different amounts of time to respond. Bitp.it was almost beat in announcing their own block by mainframe. I can improve the results by tweaking like this (if I was only looking at the above results and not evaluating pool delays over many blocks):
[mmf]
lp_penalty: 4
[deepbit]
lp_penalty: 4
[mineco]
lp_penalty: 4
[bclc]
lp_penalty: 3
[eclipsemc]
lp_penalty: 2
[arsbitcoin]
lp_penalty: 2
[eligius]
lp_penalty: 0
[bitp]
lp_penalty: 3? (would need to evaluate blocks they didn't solve)
I will test this out and see if it can completely fix false pool block designation. Of course what would be wishful thinking would be if bithopper could learn for itself the average delays it sees from each pool.
Mainframe Mining Cooperative OFFICIAL NOTICE:
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
We aren't referring to your pools luck or speed, etc. You are performing poorly as far as your lazy miners, er I mean 24/7 miners, are concerned. Since it's clearly a matter of Vladimir making all the money and nobody else making anything, you took the opportunity of the 2 hopper myth to change your payout scheme. Please provide your evidence that you had 2 hoppers. Also please define what identified these 2 people as "hoppers".
After carefully monitoring the situation I observed that AnnihailaT is stealing blocks and declaring valid shares as stales to cheat the non-Vladimir 24/7 miners.
It's easy to say anything. Harder to prove.
Im officially done conversing with you at this level and will provide you no such proof. I need not justify the implementation of a cheat proof reward system to a cheater.
@dumbceleron
You are one confused or conflicted dude. You spend the time demonstrated above to help improve hopping methodologies and then decry the act of hopping as though it's unethical. It's as if you came up with a more efficient way to kill jews, shared it with Hitler and then decried the horrors of nazi genocide (yes - I'm going straight to fulfilling Godwin's Law! why wait?). I especially love
Who is this we you refer to? You are a man without a side in this argument. No one wants you making their case and your own case is just a confused mess. You have no credibility so stop interjecting yourself... you are just auseful useless idiot.
I did some in-depth analysis of Bithopper Long-Poll timing method for identifying block-solving pools, initially to see how pool-delay corrections can be used to make round-finding results more accurate, I used the console log output of BH, which after some grepping, looks like this:
(round 141030 - found by deepbit)
We see above, the first pool to respond is NOT the finding pool!
I have workers logging into 16 different pools; however only 11 of those reply with new block LP pushes. Current Bithopper logic simply guesses that the first LP is the finding pool; as we can see in above, the first LP was not from deepbit in this case. As I had seen this behavior before, I requested the addition of an lp_penalty option - a per-pool option in Bithopper, where you can "delay" the LP reponse time on fast-reporting pools.
Now, we must classify what that delay should be. I used the LP timestamps from the console log as shown above. I was originally expecting the finding pool to clearly stand out, with a definitive earlier LP push after correction, but even this turned out not to be the case, so I should have modded the output to be tenths of seconds for better analysis before I started..
Here is 11 rounds of data, with the actual finding pool verified with digbtc.com and pident.artefact2.com. The block delays for each pool and each round are normalized against the time of the finding pool, if present:
The time-delay table is the top, different analyses are in blue, and the actual correction I am using is on is on the far right. Note the lp_penalty setting would be the opposite of this correction - eligius might get lp_penalty:0 and mineco: 4.
The bottom table is the time delays after applying the best correction I could hand-tweak. We see that still the finding pool almost never is the fastest (highlighted in red). (This might improve with 1/10th second stats resolution).
However, we see that if we average all pool LPs after learning a delay correction, the finding pool does begin to stand out.
The conclusions I have to make:
-Per-pool LP delays are more random than one might expect; and some pools have more variation than others (likely related to number of miners, and their p2p distance from block-solving pool)
-Deepbit's block-find LPs do not clearly stand out from other non-finding LPs received from deepbit,
-The first reporting pool, even when testing many delay correction formulas, will not necessarily be the finding pool.
-Only with a time delay correction for each pool, and then comparison of each pool to the average of all pools can we hope to reliably identify the stand-out block-finding pool. We also need a confidence factor, so if no pools stand out, we can conclude none of LP-returning pools we check found the block.
We have also seen --p2pLP come to prominence, where LP block-finding information is shared on IRC, and then a vote helps further refine results. However this still is very rudimentary; and as nearly all bH users get LPs from deepbit vs only some getting other pools, deepbit tends to win votes undeservedly (and these biased voting results would be more wrong if it wasn't for DB being the largest pool).
So to improve BH LP block finding to the point of reliability, we need:
- Self-learning of per-pool LP delays (LP delay learning must remove the finding pool however, or else we bias deepbit's delays because they find so many blocks)
- Publishing of all local corrected new block LP results to IRC, not just winning pool (perhaps JSON format, like "** block 3fe33a: {"triple": 0.0, "bitp": 0.3, "deepbit": 0.5, "mineco": 1.3, "bclc", 1.7}"
- Averaging (not voting or first response) all IRC results (including pools we don't actually check ourselves), to determine if there is a clear LP block winner; a confidence level can be assigned.
For the super-advanced, it may even be able to profile a 'signature' of block delays to determine who found the block, since pools also seem to have a different LP delay depending on their p2p distance from the finding pool.
(round 141030 - found by deepbit)
[1295][23:39:34] LP Call mining.mainframe.nl:8343/LP
[1326][23:39:35] LP Call pit.deepbit.net:8332/listenChannel
[1333][23:39:35] LP Call mineco.in:3000/LP
[1334][23:39:35] LP Call eu1.triplemining.com:8344/LP
[1341][23:39:36] LP Call arsbitcoin.com:8344/LP
[1344][23:39:37] LP Call uscentral.btcguild.com:8332/LP
[1355][23:39:38] LP Call pool.bitclockers.com:8332/LP
[1356][23:39:38] LP Call pool.bitp.it:8334/longpoll
[1358][23:39:39] LP Call bitcoins.lc:8080/LP
[1392][23:39:42] LP Call su.mining.eligius.st:8337/LP
We see above, the first pool to respond is NOT the finding pool!
I have workers logging into 16 different pools; however only 11 of those reply with new block LP pushes. Current Bithopper logic simply guesses that the first LP is the finding pool; as we can see in above, the first LP was not from deepbit in this case. As I had seen this behavior before, I requested the addition of an lp_penalty option - a per-pool option in Bithopper, where you can "delay" the LP reponse time on fast-reporting pools.
Now, we must classify what that delay should be. I used the LP timestamps from the console log as shown above. I was originally expecting the finding pool to clearly stand out, with a definitive earlier LP push after correction, but even this turned out not to be the case, so I should have modded the output to be tenths of seconds for better analysis before I started..
Here is 11 rounds of data, with the actual finding pool verified with digbtc.com and pident.artefact2.com. The block delays for each pool and each round are normalized against the time of the finding pool, if present:
The time-delay table is the top, different analyses are in blue, and the actual correction I am using is on is on the far right. Note the lp_penalty setting would be the opposite of this correction - eligius might get lp_penalty:0 and mineco: 4.
The bottom table is the time delays after applying the best correction I could hand-tweak. We see that still the finding pool almost never is the fastest (highlighted in red). (This might improve with 1/10th second stats resolution).
However, we see that if we average all pool LPs after learning a delay correction, the finding pool does begin to stand out.
The conclusions I have to make:
-Per-pool LP delays are more random than one might expect; and some pools have more variation than others (likely related to number of miners, and their p2p distance from block-solving pool)
-Deepbit's block-find LPs do not clearly stand out from other non-finding LPs received from deepbit,
-The first reporting pool, even when testing many delay correction formulas, will not necessarily be the finding pool.
-Only with a time delay correction for each pool, and then comparison of each pool to the average of all pools can we hope to reliably identify the stand-out block-finding pool. We also need a confidence factor, so if no pools stand out, we can conclude none of LP-returning pools we check found the block.
We have also seen --p2pLP come to prominence, where LP block-finding information is shared on IRC, and then a vote helps further refine results. However this still is very rudimentary; and as nearly all bH users get LPs from deepbit vs only some getting other pools, deepbit tends to win votes undeservedly (and these biased voting results would be more wrong if it wasn't for DB being the largest pool).
So to improve BH LP block finding to the point of reliability, we need:
- Self-learning of per-pool LP delays (LP delay learning must remove the finding pool however, or else we bias deepbit's delays because they find so many blocks)
- Publishing of all local corrected new block LP results to IRC, not just winning pool (perhaps JSON format, like "** block 3fe33a: {"triple": 0.0, "bitp": 0.3, "deepbit": 0.5, "mineco": 1.3, "bclc", 1.7}"
- Averaging (not voting or first response) all IRC results (including pools we don't actually check ourselves), to determine if there is a clear LP block winner; a confidence level can be assigned.
For the super-advanced, it may even be able to profile a 'signature' of block delays to determine who found the block, since pools also seem to have a different LP delay depending on their p2p distance from the finding pool.
You are one confused or conflicted dude. You spend the time demonstrated above to help improve hopping methodologies and then decry the act of hopping as though it's unethical. It's as if you came up with a more efficient way to kill jews, shared it with Hitler and then decried the horrors of nazi genocide (yes - I'm going straight to fulfilling Godwin's Law! why wait?). I especially love
Quote
So to improve BH LP block finding to the point of reliability, we need:
Who is this we you refer to? You are a man without a side in this argument. No one wants you making their case and your own case is just a confused mess. You have no credibility so stop interjecting yourself... you are just a
Mainframe Mining Cooperative OFFICIAL NOTICE:
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
After careful monitoring of our current situation, we have determined that the erosion of income from our loyal miner has no longer become merely negligible due to pool hopping.
We aren't referring to your pools luck or speed, etc. You are performing poorly as far as your lazy miners, er I mean 24/7 miners, are concerned. Since it's clearly a matter of Vladimir making all the money and nobody else making anything, you took the opportunity of the 2 hopper myth to change your payout scheme. Please provide your evidence that you had 2 hoppers. Also please define what identified these 2 people as "hoppers".
After carefully monitoring the situation I observed that AnnihailaT is stealing blocks and declaring valid shares as stales to cheat the non-Vladimir 24/7 miners.
It's easy to say anything. Harder to prove.
You are seeing typical pool hopper vitriol here. I responded to such a nonsensical rant here. Lulz abound as they reply with the same rehashed talking points to justify hopping to themselves.
They come up with stupid mistruths they say to each other, like "pool hoppers help pools", "this pool sucked until we added it", "xxx is hopper-friendly and now they don't suck", "nobody was making any money until pool hoppers came along anyway", "we are smarter than other lazy pool miners", "it's not our fault they use an unfair system", "xxx pool is a bunch of unethical jerkoffs for blocking hoppers", or as above "we don't even matter to your pool". Well, it's right there ready to go in the config file of bithopper, all you have to do is put in your credentials and wait for a new block, as clearly some had.
The truth is: whether a proportional pool has a high or low hashrate, it makes the miner exactly the expected amount over time, until pool-hoppers start jumping on and exploiting it, what Raolo aptly titles "pool cheating" in his initial publication of the exploit (one that was quickly apparent to me when I started mining too, and then I searched and found the long-ignored threads and didn't bump the topic.)
Even if a pool was just Vlad mining by himself, that only amplifies the need for counter-measures or an unhoppable payout system. Imagine he just got done mining on a long block, and says to himself, "well, it's just variance, at least I'll make it up on the short rounds". Then a new round comes and a whole shitload of people pile on the pool and it turns out to be a 30 minute round that he hardly had time to submit shares into. Now he doesn't get squat for the short round. Same thing goes on every other pool, the expected mining revenue is reduced directly as a ratio of regular miners to pool hoppers.
They come up with stupid mistruths they say to each other, like "pool hoppers help pools", "this pool sucked until we added it", "xxx is hopper-friendly and now they don't suck", "nobody was making any money until pool hoppers came along anyway", "we are smarter than other lazy pool miners", "it's not our fault they use an unfair system", "xxx pool is a bunch of unethical jerkoffs for blocking hoppers", or as above "we don't even matter to your pool". Well, it's right there ready to go in the config file of bithopper, all you have to do is put in your credentials and wait for a new block, as clearly some had.
The truth is: whether a proportional pool has a high or low hashrate, it makes the miner exactly the expected amount over time, until pool-hoppers start jumping on and exploiting it, what Raolo aptly titles "pool cheating" in his initial publication of the exploit (one that was quickly apparent to me when I started mining too, and then I searched and found the long-ignored threads and didn't bump the topic.)
Even if a pool was just Vlad mining by himself, that only amplifies the need for counter-measures or an unhoppable payout system. Imagine he just got done mining on a long block, and says to himself, "well, it's just variance, at least I'll make it up on the short rounds". Then a new round comes and a whole shitload of people pile on the pool and it turns out to be a 30 minute round that he hardly had time to submit shares into. Now he doesn't get squat for the short round. Same thing goes on every other pool, the expected mining revenue is reduced directly as a ratio of regular miners to pool hoppers.
We dont have a disease and havent complained anywhere about poor results. have you checked out luck over the last 25 blocks ? We have been exceeding expectations.
Where are you getting this from ?
Where are you getting this from ?
Why is there any reason to cover anything? No need for smoke... We cant be any more honest. We dont approve of even a small amount of hoppers taking BTC away from the 24/7 miners that stick with us when the luck is good and when its bad. For this reason we have decided that a purely proportional reward system is not in the best interest of the miners who form the base of this pool at the moment. It really doesnt have anything to do with approval or disapproval of the proportional implementation.
BTW, why so hostile and aggressive? Did we piss in your cereal or something?
BTW, why so hostile and aggressive? Did we piss in your cereal or something?
First off, my response was based on your reason about poor results on your pool. You are using smoke and mirrors that has no relation to the performance to simply make things easier for yourself with regards to the pool lack of solving blocks.
This in itself is a lame attempt of passing the buck considering we(and no other hopper I know) would hop anywhere near mmf considering the payout setup you have had thus far.
Im only hostile and aggressive when strawman(or fudgeman) statements are being made that isnt related to anything yet bloated as if it is the cause of your disease.
What? I've thought you were Score-based for as long as I've known about you. Seriously, any erosion your miners may be experiencing has nothing to do with hoppers. Generally, hoppers haven't touched your pool... you and eclipse both have been unhopped for weeks. Don't try to scapegoat hoppers for poor performance in your pool.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
We began as scored based but realized that the implementation was broken and quickly switched to proportional shortly thereafter. this was announced on the website and on the official forum threads.
Who said anything about poor performance? This pool is performing extremely well given its hash rate and noone is complaining about about performance much less looking for a scapegoat.
Regarding the hopping. It just started last nite and noone claimed it was massive or coordinated. We picked up 2 hoppers with hashing power totalling around 31 gh/s. For a pool this size, that makes a significant difference for the 24/7 miner and was enough incentive to do something about it. Thats it.
Quote
Pointing out that hoppers is affecting MMC is a big joke.
This pool was never "poolhopper friendly" and this is merely smoke to cover up why you are moving to PPLNS now, rather be honest and state that you just didnt approve of your previous implementation.
This pool was never "poolhopper friendly" and this is merely smoke to cover up why you are moving to PPLNS now, rather be honest and state that you just didnt approve of your previous implementation.
Why is there any reason to cover anything? No need for smoke... We cant be any more honest. We dont approve of even a small amount of hoppers taking BTC away from the 24/7 miner that stick with us when the luck is good and when its bad. For this reason we have decided that a purely proportional reward system is not in the best interest of the miner who forms the base of this pool at the moment. It really doesnt have anything to do with approval or disapproval of the proportional implementation.
BTW, why so hostile and aggressive? Did we piss in your cereal or something?
Fixed that for ya.
What? I've thought you were Score-based for as long as I've known about you. Seriously, any erosion your miners may be experiencing has nothing to do with hoppers. Generally, hoppers haven't touched your pool... you and eclipse both have been unhopped for weeks. Don't try to scapegoat hoppers for poor performance in your pool.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
We began as scored based but realized that the implementation was broken and quickly switched to proportional shortly thereafter. this was announced on the website and on the official forum threads.
Who said anything about poor performance? This pool is performing extremely well given its hash rate and noone is complaining about about performance much less looking for a scapegoat.
Regarding the hopping. It just started last nite and noone claimed it was massive or coordinated. We picked up 2 hoppers with hashing power totalling around 31 gh/s. For a pool this size, that makes a significant difference for the 24/7 miners and was enough incentive to do something about it. Thats it.
Quote
Pointing out that hoppers is affecting MMC is a big joke.
This pool was never "poolhopper friendly" and this is merely smoke to cover up why you are moving to PPLNS now, rather be honest and state that you just didnt approve of your previous implementation.
This pool was never "poolhopper friendly" and this is merely smoke to cover up why you are moving to PPLNS now, rather be honest and state that you just didnt approve of your previous implementation.
Why is there any reason to cover anything? No need for smoke... We cant be any more honest. We dont approve of even a small amount of hoppers taking BTC away from the 24/7 miners that stick with us when the luck is good and when its bad. For this reason we have decided that a purely proportional reward system is not in the best interest of the miners who form the base of this pool at the moment. It really doesnt have anything to do with approval or disapproval of the proportional implementation.
BTW, why so hostile and aggressive? Did we piss in your cereal or something?
Prop. pools that allow hopping should just die a natural death already. (Or delay stats like deepbit/bitcoins.lc)
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Yeh we started to recently see the problem getting alot worse. You can see on ozco.in for example that in the last week or so each time they solve a block they immediately jump up by around 220 GH/s over their normal 60-80 GH/s. That's ALOT of hopping. Looks like this is becoming a real trend for miners much more lately than say a month ago or more.
Im not even sure with tools like pident.artefact2.com/org if delaying stats is effective anymore. You can pick the data up via other methods lately.
No hopper would touch your pool if they are worth anything.
Pointing out that hoppers is affecting mmf is a big joke.
This pool was never "poolhopper friendly" and this is merely smoke to cover up why you are moving to PPLNS now, rather be honest and state that you just didnt approve of your previous implementation.
What? I've thought you were Score-based for as long as I've known about you. Seriously, any erosion your miners may be experiencing has nothing to do with hoppers. Generally, hoppers haven't touched your pool... you and eclipse both have been unhopped for weeks. Don't try to scapegoat hoppers for poor performance in your pool.
Seriously, since July 18th, the bitHopper crowd has had no use for you:
https://bitcointalksearch.org/topic/m.375454
No really, since there has been a separate config file, your pool has been listed as not hopped for a reason:
https://github.com/c00w/bitHopper/blob/088380c2a5698f1d81b7c2349dc44db5e41041f4/user.cfg.default#L108 <- That commit is from July 31st.
I mean it, your pool hasn't been hopped for at least a month. This commit from July 21st shows your pool listed in the Not hopped for a reason section:
https://github.com/c00w/bitHopper/blob/4133048b07213fd0561c08a84f7cd95bf56de774/pool.cfg.default#L107
And here is the latest info committed 3 hours ago:
https://github.com/c00w/bitHopper/blob/master/POOLS_INFO#L214
You can check the history of these files to see that the primary method for hopping hasn't hopped your pool for a month, if ever.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
Meanwhile, hopper friendly pools are growing.
Best of luck with PPLNS.
Seriously, since July 18th, the bitHopper crowd has had no use for you:
https://bitcointalksearch.org/topic/m.375454
No really, since there has been a separate config file, your pool has been listed as not hopped for a reason:
https://github.com/c00w/bitHopper/blob/088380c2a5698f1d81b7c2349dc44db5e41041f4/user.cfg.default#L108 <- That commit is from July 31st.
I mean it, your pool hasn't been hopped for at least a month. This commit from July 21st shows your pool listed in the Not hopped for a reason section:
https://github.com/c00w/bitHopper/blob/4133048b07213fd0561c08a84f7cd95bf56de774/pool.cfg.default#L107
And here is the latest info committed 3 hours ago:
https://github.com/c00w/bitHopper/blob/master/POOLS_INFO#L214
You can check the history of these files to see that the primary method for hopping hasn't hopped your pool for a month, if ever.
Any hopping your may experience would be incidental and uncoordinated. It's more likely that nobody is making any money in your pool because it's essentially a hash-boosting mechanism for Vladimir who alone has 60% of your pools hashrate and likely makes 70%+ of your pools reward. You are not affected by hoppers, you would be lucky to have hoppers so that you weren't in effect a one man pool.
Meanwhile, hopper friendly pools are growing.
Best of luck with PPLNS.
Prop. pools that allow hopping should just die a natural death already. (Or delay stats like deepbit/bitcoins.lc)
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Yeh we started to recently see the problem getting alot worse. You can see on ozco.in for example that in the last week or so each time they solve a block they immediately jump up by around 220 GH/s over their normal 60-80 GH/s. That's ALOT of hopping. Looks like this is becoming a real trend for miners much more lately than say a month ago or more.
Im not even sure with tools like pident.artefact2.com/org if delaying stats is effective anymore. You can pick the data up via other methods lately.
Prop. pools that allow hopping should just die a natural death already. (Or delay stats like deepbit/bitcoins.lc)
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Theft from 24/7 users has been going on for ages. It's the worst reward model out there.
PPLNS is a good alternative which requires no startup capital at all.
Jump to: