@realbminer: you are using the same seed for the nonce every time a new job is sent by the pool ... this is bad programming. When multiple rigs running bminer are connected to a proxy, they all receive the same job (proxy broadcasts it). Normally, each rig should start with a random seed, and hence find different solutions below the target. However, bminer always starts with the same seed, and the rigs find the same solution, they all submit it, the pool accepts only the first one and rejects all the others, and then bminer finally craps out with "too many invalid solutions".
p.s. For any experts out there, including @realbminer: No, the proxy should not relay all messages in order to get different jobs for different rigs. A true proxy should be able to act like a single miner, the pool sending only one job, then the proxy broadcasts to all rigs and merges replies from rigs to the pool. The purpose is reduce communication overhead from the pool and hence also reduce likelihood of stale shares.
I don't think I'm misunderstanding you, in the case that I am, please correct me...
I've done a fair bit of research into proxies and the stratum protocol - I've been building a multi-coin proxy myself, we should compare notes - my findings are somewhat different than yours.
MANY mining devices/binaries will just start their calculations at zero and increment; I agree that it's somewhat better to 'randomly seed', but it IS perfectly valid to just increment. You're right, with this type of tactic, in the multi-rig scenario you mention, it's absolutely possible and in fact highly likely to hit duplicate shares early without some sort of intervention. However, the solution to this isn't in the miner (you cannot control how all past and future mining binaries will do this, after all).
Think about this for a second: the pool assigns each miner connection a unique nonce1 value. This gives each connection a unique 'nonce-space' in which to calculate solutions. If every connection to the pool is a miner, then there won't be any duplicate shares submitted. However, if a connection to the pool is a proxy, it still only receives a single nonce1 value and it has to 'share' that nonce1 value with all miners that connect to it. With this in mind...
The better solution lies in the proxy itself (particularly since you cannot control all miners out here)! If you examine how other proxies handle this, they 'assign' a unique nonce space to each miner connection by assigning one or two (unique) bytes per worker connection. For each miner connection to the proxy, this byte value is appended to the nonce1 value (originally received from the pool); and as you know the miner receives this unique nonce1 in their 'mining.subscribe' stratum request.
So, a proxy needs to send the pool's nonce1 + unique byte value per connection (ie. per rig) on subscription, and when a share is submitted from a rig the proxy needs to prepend the rig's unique byte value to the calculated nonce before sending it on to the pool.
There are caveats to this approach; with a single extra byte, you're limited to 256 miners connecting to that proxy. With 2 bytes extra, you get up to 65536 connections allowed. Most other popular proxies I've examined follow this approach, rather than rely on consensus and a common tactic used in miners.
I have this working, and have
confirmed that bminer only supports up to 256 because it's hard-coded to only allow a single extra byte to be appended to the nonce (based on my investigation, I believe this was done to support Nicehash, which is like a proxy).
realbminer, if you're reading, you should really look at allowing another extra byte in the nonce1 length to give miners more flexibility - and more proxy compatibility.