BitBar and BBQCoin added to Cryptoswitcher. SolidCoin removed.

I would like to know this too, and if there is anything that could be done to make it easier to run on Windows, I'd look into it.

With thanks to open5443 on GitHub, the latest round of updates supports using Dustcoin and Coinchoose at the same time, and CHNCoin has also joined the party.

I wrote CryptoSwitcher to do something like this locally (see the link in my sig).

I have been thinking about the difficulties of doing something like what you suggest for a while now though, and implementing CryptoSwitcher as a service. Two instances of CGminer would have to be run locally, as you have already identified. In addition to that, most people use different clocks for Scrypt and SHA256 coins. Allowing a remote service to set your clocks is a recipe for disaster, so most people would have to either accept inefficient clocks for mining SHA256 coins, or run an additional daemon locally to switch clocks as required.

The difference between what you suggest and what I'm suggesting is that the theoretical service I have in mind is one that switches you between pools mining the different altcoins. You are suggesting a single pool that runs pools for all possible coins, and changes the work fed to the miners. My interpretation is easier for the operator, in that he doesn't have to do all of the heavy lifting, but your interpretation is certainly easier for miners.

Neither exchange supports auto-withdrawal via the API, so I don't see that feature being implemented soon, I'm afraid.

The default 1MH/s -> 1kH/s ratio is assumed (by virtue of this assumption being made by dustcoin and CoinChoose), but if that is drastically wrong for you, you can include additional fees to penalise Scrypt coins the appropriate amount. So if you get 700MH/s with SHA256, but only 600MH/s with Scrypt coins, you would include an additional fee of 1-(600/700) = 0.14 on Scrypt coins.

Again, thanks to a CoinChoose update, MinCoin has now joined the party.

I believe the requirements sal has for a coin to be added are for there to be a public block explorer, and at the very least a public orderbook if not a proper exchange.

Can you change the code for FeatherCoin in the API to FTC? See the discussion going on at  https://bitcointalk.org/index.php?topic=178286.1180

Just makes everything more consistent.

Feathercoin now supported for those using CoinChoose.

In light of this, Cryptoswitcher now also supports Feathercoin.

I'm afraid I'm not a Windows person (for mining, anyway). Is there an equivalent of pip for Windows, does someone else know?

Which OS, and what have you tried so far? What errors do you get?

Anyone interested in making a Cryptonit API wrapper for Python?

How often would you like us to ping the JSON feed? The graphs clearly show that the hourly update I currently use for CryptoSwitcher is inadequate; if I changed that to, say, five minutes, would that be okay by you?

A blind bounty, you say. Well, whatever you think the changes I've just pushed are worth...

I'm sure it's a total coincidence that the first proper update from BFL for a couple of weeks is made on the same day that Avalon claim to have started ('slowly') shipping their second batch.

I would prefer to keep that sort of configuration in the CGminer config files that people probably already have. In addition, you have to restart CGminer to switch from an Scrypt coin to a SHA256 coin, unless I'm missing something drastic in the API, so this is unable to be done purely with a single CGminer instance and the API. I think I know how I want to approach this.

Agreed, I've been thinking about this too and looking into the CGminer API. For now, I can only recommend you have backup pools in your CGminer configuration files, but I realise that for the more exotic coins that's probably easier said than done.

Fizzisist seems to be back up, but is now returning 'null' for profitability, which I had never seen before. I have pushed an update that handles this gracefully.

The first post had errors in the URLs for those three (I'm too used to BBCode), which I have now corrected.