I'm not sure if conman feel terribly inclined to make changes that accomodate merged mining but I've come across a serious issue that is cgminer specific so perhaps in this case he may make an exception. If some of my assumptions here are wrong my apologies but I've observed it's behaviour and looked through the source code and I'm fairly sure I've interpreted it correctly...
The problem is summarised here:
https://bitcointalksearch.org/topic/m.593497cgminer may be a bit too clever for it's own good. It does it's own checks on whether work is valid and I presume it uses prev_block_hash to check or maybe the X-Blocknum header. If an NMC block is found but it isn't a BTC solution then the pseudo block number will advance but the X-Blocknum header (which is for BTC block in psj) and the prev_block_hash won't change. So cgminer may think it's the same block and carry on using it's cached work.
and a bit more detail here:
https://bitcointalksearch.org/topic/m.594007The end result is that cgminer refuses to acknowlege that the block has changed as it doesn't accept LP as an authoritive indicator that it should discard it's local work and use the new work. This means, particularly in the case of PPS pools, that pools are likely to penalize cgminer users by either not awarding the share at all or only giving them a partial credit.
Depending on which policy they choose this could end up costing the miner either a significant chunk of their namecoin rewards or possibly even a large chunk of bitcoin rewards. I'll go through the scenario and the possible effects:
pool rejects partial shares:What happens is this: The BTC and NMC blocks change but at slightly different times. If the BTC block changes first cgminer get LP and acts on it as it sees a new prevblockhash. A few seconds later the NMC block changes. This doesn't change the prevblockhash so cgminer carries on with the work it already has. When it submits a share the pool sees that it's only valid for one of the blockchains and rejects it as stale. This continues for as long as cgminer would normally hold onto the same work (up to 60 seconds) or until the BTC block changes again. In between BTC block you'd usually exepct several NMC blocks as the difficulty is lower. Se even if cgminer has given up the work after 60 seconds, as soon as another NMC comes along the same situation occurs. The miner is working on work that is only valid for one chain.
This is not theoretical it's really happening and it's being hugely under reported on most pools (see next para for explanation of that), I've seen it in testing and on production pools. Overall stales are a little higher they were pre-merged mining which is partly to do with more frequent block changes and partly due to some design clashes between merged mining and longpolling. But cgminer stales are typically many times higher than for other miners. The 'dumb' miners (i.e. the one's just accept new work from the LP and don't check if it's a new block) work fine because they trust that the pool is right when it says 'new block'.
Many merged mining pools which aren't using poolserverj probably have this problem also but it's invisible to them. Merged-mining-proxy does not do any sort of LP and unless the pool ops have made some fairly invasive changes to pushpool it won't be internally aware of changing block on different chains either. I suspect they've just been accepting shares they shouldn't have. When they all start to realise what's going on expect some policy changes from these pools.
The fix seems fairly simple on the surface but the devil is always in the details... I think conman is not keen on blindly accepting LPs as some pools send out bullshit LPs occasionaly (even poolserverj does if the block doesn't change after 10mins). But it needs to be an option. Perhaps a command line switch that miners can use only if they are merged mining. All it needs to do is replace the work it's currently hashing with the contents of the longpoll (regardless of whether prevblockhash is different) and clear it's cache. There's no cost to doing this except perhaps a few getworks to fill up it's cache again.
