I did some additional testing today to validate that everything is working as intended code-wise. This is the page of the Ropsten-Testnet account: https://ropsten.etherscan.io/address/0x0942e9144606ad43f2e61a7ee332fe9914424712#mine

You're welcome :-)

Did my suggestion work for you?

The message about mining.extranonce.subscribe not being supported is harmless. It's about an optional stratum message that pools are not required to implement.

The issue with finding shares could be attributed to the stratum difficulty of port 3047. I suggest connecting to port 3046 which supports a much lower minimum difficulty BUT like all ports on all ports an unlimited maximum difficulty. The vardiff algorithm will adjust the difficulty until your miner submits shares with the optimal interval.

Hey Andy

Like I said I don't blame the miners leaving a pool with bad luck. It has become quite hard these days to get a pool to take off. They only way to do that with so much competition in the mining space is persistence and good support for the miners.

It's funny that you mention moneropools.com. I've been in contact with M5M400 (the guy running the site) about adding our site when poolmining.org was very young. For some unknown reason that never happened. But just this morning I wrote him on reddit about this. 

I was suspecting that legitimate questions like this would come up if the bad luck streak would continue as it did. Under normal circumstances where the pool would find blocks from time to time, answering this would be easy since the pool's address 0x6eb231d41a8f33df4bce885c5b450655d5390ce8 would be traceable on the blockchain and altering it would be highly suspicous. But since that hasn't happened so far, the only possible way to prove it would be to run a script against etherscan.io's API checking the "miner" field of every single block that was mined during the past weeks. I'll try to provide something like that as it could be also useful for other pool ops.

This is how parity is launched for the Ethereum pool:

/usr/bin/parity --chain mainnet --base-path "/data2/ethd1" --mode "active" --no-ui --no-dapps --jsonrpc-interface "127.0.0.1" --jsonrpc-threads 4 --no-discovery --jsonrpc-apis "eth,net,web3,personal,parity,parity_pubsub,rpc" --ipc-path "/data2/ethd1/geth.ipc" --author 0x6eb231d41a8f33df4bce885c5b450655d5390ce8 --cache-size 512 --logging "info" --no-ws

.. and the Ethereum Classic Pool:

/usr/bin/parity --chain classic --base-path "/data2/etcd1" --mode "active" --no-ui --no-dapps --jsonrpc-interface "127.0.0.1" --jsonrpc-threads 4 --no-discovery --jsonrpc-apis "eth,net,web3,personal,parity,parity_pubsub,rpc" --ipc-path "/data2/etcd1/geth.ipc" --author 0x4d441a184ba7a22551292b8af3506956901a705e --cache-size 512 --logging "info" --jsonrpc-port 8546 --port 30304 --no-ws

This of course proves nothing as I could make this up if I had ill intents. If there was a way to incorporate the wallet address the pool is using into the stratum mining protocol, I would implement it in a heartbeat. 

I did. They refuse to add any pool they didn't test themselves. As to why they don't simply test it. No idea.

@Xima Thanks for your incredibly kind words. :-)

Weird. I've checked the logs. There was not interruption for the other miners on any of the pools during that period.

:-)