Halo I explained that high orphan rate is not related to high hash rate at another pool. There is way too many factors to this. You can ask the other pool owners if they are having the same problem. All the pools get orphans, and it occurs more when the block time is faster. But your persistence to blame the orphan problem on us is beyond me. Why would our hashrate cause orphans at one pool and not another?
I know exactly why you are having issues and I posted it earlier on this thread. If you had bothered to read my advice you would not have been in this situation. I said it once and say it again once your pool reach 270MH it will fail, did you believe me then NO, and when the ddos hit our pool the quick jump on your pool put you over that fail line. So the fail came sooner than later. And it was compounded by the ddos on us to a point of no return.
Every time our pool went down for a little bit, the problem at your pool was growing. If you remember the first day of UTC launch, IDcray had the same issue because they had high hashrate from day one, and they closed signups quickly because they did not know how to deal with it. Now you want more, when the next Nfactor kicks in the fail line will be at 180MH after which a small pool will fail to operate. Our creation of Nitro 2 is mainly to satisfy the community, and bring some peace to this thread. It's a shame we have to keep going back to this. Read my earlier posts on this thread about these issues.
As for your suggestion for pool resistant hash diff etc.., please read it again. If your suggestion is practical I would be mining UTC blocks on a CPU at 0.000001 difficulty and you will be mining it at your pool at 5 or 6 diff.
i was not aware of your explanation earlier in the thread. I must have skipped it somehow or I misinterpreted it. Makes sense about the first half of what you said. My apologies. Thanks for explaining again. Laterbreh just confirmed what you said that it was with our pool, and answered why other pools had 0% orphans.
As for my suggestion, yes, you kinda got the idea, but you exaggerate what I mean with your numbers and you are too ''early'' on the exponential curve (E curve), as i explain. you're saying my idea lets it be easier for cpu's but not for gpu's just like the effect n-factor has, getting paid the same for more work. I agree, but thats not my starting point. My idea is not as detrimental to the little guys as to encourage several medium sized pools instead of one huge pool. what is the maximum hashrate for a cpu, ~170? max hashrate for gpu is 1000 give or take. scale the diff like an E curve. yes gpus would have higher diff, thats the point and is already seen in nfactor.
But you dont have to do what I just explained. Gives the feel of my idea. The E curve could be set so that every farm or pool hashrate up to, lets say 100MH or if we want a percent of net hashrate - we'll say 30%, is still in the same diff group as one card with 50KH. Anything past the the 100MH or 30% would start to skyrocket. This results in the E curve effects taking off and targeting huge pools to encourage hashes spreading out. diff would be based on: hashrate divided by total net hashrate times 100. 1 pool owner could have several larger-medium-sized pools. Nitro 1, 2, 3 and so on. All my numbers would have to be tweaked, i'm only using examples. Could use percentages of net hashrate instead of a written in stone interger to allow flexibility and growth. Thoughts?
Coinwarz would have fun with this one.... lol