I think this is how it works:

In order to submit the block solo, you'd have to change the address to which the block reward is payable to be one that you control.  And you'd have to do this before solving the block, otherwise you'd change the hash.  A pool operator obviously isn't going to accept a share where you've modified the coinbase transaction to change the address the block reward is paid to - so your shares would simply be rejected.

Yes, it's true that the one thing the pool operator knows but you don't is the private key of the address that the block reward is payable to - but that's really answering a different question, namely: "why can't you spend someone else's coins?"

roy

Yes but as I said on the previous page - the variable diff version of that can be calculated in the API
However ...
You can also find the two numbers on the screen with: P I n Enter (where n is the pool number)
So from there divide "Accepted difficulty shares:" "Getworks"

Sure, I've chosen the values arbitrarily at this point, because I wasn't sure what optimal values would be. 

Why do you choose 20, just out of curiosity?  I chose 8 at first, but that seemed to really crank the difficulty, then 12... we can move to 20 and see how that plays out.

20 would allow for larger miners to have less variance in share submission which is usually the reward for have a larger hash rate at Diff 1. For 1Gh/s, share submission should be around 13.85 shares per minute. By having a number higher than 13.85, it still allows larger miners to have slightly less share variance while still limiting the overall pool resources the large miners are taking up.

So, mining with 1 5970 and 2 BFL mini rigs the results are:

US1 @ 12 getworks == diff between 50 and 75
US2 @ 16 getworks == diff between 40 and 50
US3 @ 20 getworks == diff between 30 and 40

I am really liking US3 with almost 1/2 the diff of US1. This has definitely helped bring share variance down and the swings in the diff changes as the server re-targets the diff.

You might want to keep a minimum diff for each user mining so that once they start mining for the first time, the system will remember a minimum difficulty for that particular miner. That way, if someone with 10Th/s hops on and off the server, they don't start with diff 1 shares everytime.

Just my two bitcents. 

US2 is having some trouble, I am investigating it now. 

I'm pointing my measly 5g/h here now.  So far I like the interface.  Note to self, and others, if switching from a pool where the workers were user.miner to eclipse, change it to user_miner if you expect to see anything.  Otherwise it happily mines away, presumably to never never land.

Q: are you keeping transaction fees?  I assume you need something to pay for this, unless you have some happy donators.

M

Nevermind, too tired, had launched an earlier cgminer. Sorry for the fuzz.

I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.

I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.

What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?