@wetblanket - what you propose is not always feasible (depends on the algo, pool and miner; e.g. dstm rejects it, zpool.ca does not even send a nonce1; i also couldn't make it work like you explained with bminer).
Any statum-like protocol requires sending a nonce1, as miners require it; it's their unique pool-designated nonce-space in which to generate solutions and this prevents duplicates at the pool - so yes, zpool must send it:
{"method": "mining.subscribe", "id": 1, "params": ["test/1.0.1", "", "equihash.mine.zpool.ca", 2142]}
{"id":1,"result":[[["mining.set_target","0001fffe00000000000000000000000000000000000000000000000000000000"],["mining.notify","14b0d7e249321c064e953398291e723b"]],"810092d3"],"error":null}
"810092d3" above is the nonce1. What equihash does NOT send (unlike other stratum-like protocols) is the
nonce2_size (usually about 4), which indicates the size of the nonce2 solution the pool is expecting to receive in a "mining.submit" share.
Equihash takes a different approach, internally defining the total nonce size to be 32 bytes long (much bigger than other algos), so the miner (and also any proxy!) can calculate the length of the nonce2 it needs to generate to satisfy a total length of 32. So:
32 - len(nonce1) == <how long the generated nonce2 must be>It shouldn't be handled in the proxy anyway ... I patched nheqminer with random seeds a long time ago because of the same issue. Also, you hit duplicate shares every single time, since every job is broadcast to all miners at the same time.
The fix is so much easier done in the miner ... just change the start seed.
For the purpose of comparing dstm and bminer it doesn't matter though.
I disagree that it's easier done in the miner, but this is mostly a matter of perspective:
- My previous point about not being able to control/patch all miners means that if you take the approach of dictating to miners that they have to change their code to your way of thinking simply means that your proxy will not be compatible with miners that choose not to do so. Patching the code isn't the hard part; it's ensuring all miners do so.
- You certainly CAN patch miners to generate nonce2 values randomly; however given the same nonce1, there is still a small chance two rigs will randomly generate the same nonce2 value. This would still result in a duplicate share. The possibility is admittedly incredibly remote, but the chance is still there.
From a different point of view: a miner cannot control what other miners are doing; only the source of information can do that. In a pool -> miner relationship, the pool fills that role. If a proxy is put in the middle, then the proxy must serve that role for its connected miners.
This is
literally the canonical proxy example, which does exactly what I'm saying. I'm not inventing this approach, I'm just describing something that already works and all but guarantees the avoidance of duplicate shares.
