NFW and I started a discussion on dev fees "by accident" on a different unrelated topic, so I thought it would be best if we move the discussion here.
NFW's reply was:
... security hole 'feature' called #xnonce to seamlessly redirect where some shares are received from/sent to (DevPool) without actually resetting/restarting a miner like changing a pool would do. The effect of using #xnonce in that manner does not show up on any miner GUI or monitoring software as all it knows is that the miner is hashing at x speed.
I believe he made a typo there, he likely refers to xnsub. My humble understanding about Xnsub is that it simply eliminates the need to re-connect to the pool with a different extranonce so pools/places like Nicehash can go about their daily business, the extranone (for those who don't know) is used to extend the number of possible hashes (nonce range) a miner can try without repeating the same hashes or runs out of nonce, given that the nonce size can't be larger than 32 bits (4 billion possibilities) with thousands of miners hashing the same block with the same coinbase inputs, overlapping can happen before the value of time changes (which will result in a completely different range of nonce), this means the pool will be wasting hash power.
So according to
Statrum protocol during "mining.subscribe/ connection" the pool will send:
mining.subscribe("user agent/version", "extranonce1")
Switching from pool A to Pool B means you will have to subscribe again to get the new pool's extranonce1, if however, you have xnsub enabled, nicehash for example will be able to pass the new extranonce1 without your miner having to reconnect so potentially you save a few milliseconds of wasted power.
mining.subscribe
mining.subscribe("user agent/version", "extranonce1")
The optional second parameter specifies a mining.notify subscription id the client wishes to resume working with (possibly due to a dropped connection). If provided, a server MAY (at its option) issue the connection the same extranonce1. Note that the extranonce1 may be the same (allowing a resumed connection) even if the subscription id is changed!
With that being said I don't know how would custom firmware utilize xsnub in that way, it is used by the pool itself, the miner can't force the pool to accept it, so if you do happen to mine to a pool that does not support xsnub what is going to happen?
I also noticed that for the gears I have Vnish firmware on my hashrate on the pool does not seem like it was interrupted, unlike when I tested Dollermizer years ago, the hashrate on the pool would look like a mountain range and the periods when the dev pool was on are so easy to spot.
Would love to know how exactly do these custom firmware go about collecting their fees, why some can do it without leaving prints on the main pool while others do? let's share our thoughts and views.