2014-10-13 22:19:01,129 INFO Pool-coint-Thread:strat.mining.stratum.proxy.worker.StratumWorkerConnection - REJECTED share (diff: 78.91852393) from 1111@/107.170.50.27:8878 on coint. Booo !!!!. Error: JsonRpcError code=20, message=incorrect size of extranonce2, traceback=null
The rejections with the bad extranonce2 size comes from a bug in cgminer3.7.2. This bug is fixed in cgminer4.x, all versions of sgminer and some cgminer3.7.2 forks. Some ASICs miners also have this problem (if their firmware is not up to date). This bug does not allow to use stratum proxies (mine, slush0 one, bfgminer...)
There is a simple solution to this: I programmed a little proxy for myself.. it takes every command from client and server and sends it to each other ( my aim: some commands get deleted, like "stratum.reconnect". my proxy then does the reconnect ). Problem: you can only have 1 client instead of 10 clients ( as extranonce2 is not changed, two clients could produce duplicate shares ).. but when multiple clients show up, i simply open new connections to the same server ( so every client has it's own extranonce1 )
This is indeed a solution, but it is not the one used for this proxy for several reasons:
-This approach is only useful (AFAIK) as a (partial) workaround for the cgminer 3.7.2 extranonce2 size bug and I consider that cgminer version as deprecated. If this version is really needed, getwork can be used behind the proxy instead of stratum. I said partial, since it will not work for some pools which have an extranonce2size > 4 (like Nicehash).
-The support of getwork with this approach is more painful (even if not impossible)
-The pool switching is a bit more complicated since several pool connections have to be managed at the same time.
I do not know if you want to release your proxy for everyone, but it would be nice. Users would have more choices and could find a proxy that matches their needs.
(You can post here the link to your proxy if it is already open-source)
anyways: as a proxy you could simply change the pool diff.. of course you could not lower it.. but if the server accepts >1024 , it should be no problem if every client sends >2048 !? ( 2048 is alway bigger than 1024 ). so you could increase the diff, and so lower network traffic, without loosing hashrate!? ( if the client is fast enough for one 2048-share /second of course... )
For the difficulty management by the proxy, I could indeed change the pool difficulty on the fly (it is in the TODO list, but not enough time, as usual). But, I can only DECREASE it, not increase it:
(Reminder: the pool take into account the number of shares sumbitted and the pool difficulty, not the real share difficulty)
-If the proxy decrease the difficulty (let's say diff1024 sent by the pool, and the proxy accept diff512 shares), the miners will sumbit twice the number of shares to the proxy. The proxy will have to check the real share difficulty sent by miners and submit to the pool only shares with diff>=1024 (else, there would be a lots of rejects with "Share above target" error). So, the hashrate estimated by the proxy will be more accurate for miners and profit will not be impacted since the pool receives the same number of shares with at least a diff of 1024.
-But if the pool increase the difficulty (let's say diff1024 sent by the pool, and the proxy accepts diff2048 shares), miners will submit only half the number of shares. So the profit will be divided by 2 since the pool receives less shares, even if the shares have diff >= 2048.
