Mining altcoins, with CryptoSwitcher deciding which to mine (currently mining Grandcoin with a 6870 and a 7750).  It also handles trading altcoins to Bitcoin. 

CryptoSwitcher can also be used with ASICs to switch between different SHA-256 coins.  My Jalapeños are currently mining Terracoin. There's usually not nearly as much difference between SHA-256 altcoins and Bitcoin as between scrypt altcoins, but there is still a difference.  Right now, Terracoin mining makes 108% of what you'd make by mining Bitcoin.  Grandcoin, OTOH, currently makes 711%.  That's a pretty potent multiplier; it makes my 470 kH/s of GPU power roughly equivalent to half of a Jalapeño. 

A couple of days or so ago, I merged some pull requests that had been sitting around a while.  I also included a PHP script that uses the cgminer API to switch pools.  Others have posted about using just one cgminer.conf with every pool and issuing a switchpool call.  My script takes a pool URL, miner name, and password, adds them to the current list of pools, and (optionally) removes all of the other pools.  In your pool-switching shell script, you then call my script once for each pool you want to use for a coin, with the "clear" parameter included on the first call. This allows you to have multiple pools configured for a coin as a backup.

The ports listed at http://lbw.ltcoin.net/help.php are incorrect.  A port scan (5000-9000) of the VM on which the Lebowski pool resides shows these ports open; the associated pools (where known) are marked:

5555/tcp YAC
6026/tcp MEC
6655/tcp FST
6868/tcp
7688/tcp
7766/tcp ANC
7951/tcp
8025/tcp
8026/tcp MEC
8706/tcp YAC
8758/tcp
8768/tcp
8833/tcp FST
8866/tcp ANC

I tried the 6 unknown ports in place of 6677 and 8855; none of them worked any better. Is the pool down?  Previous messages indicate its blockchain copy may have forked; was the pool shut down?  Is there another Lebowski pool that's known to be properly working?

Sorry...a config-file error brought the site down.  It's been fixed.  Once it was fixed, a bunch of withdrawals (including mine) went through shortly after.

A while back, I did a Bitgem fork.  It's on my pool site:

https://bitgem.dyndns.org/bitgemaddress.html

It's also at GitHub:

https://github.com/salfter/bitaddress.org

I removed the bitaddress.org logo at the top (since it doesn't really apply here), replaced the paper-wallet artwork with my hastily cobbled-together Bitgem note design, edited some of the text on the bulk-wallet tab, and changed a few constants here and there to produce Bitgem addresses.  Copyright and donation-address messages were left alone, but I figured it'd be appropriate to remove the PGP-key and version-history links and redirect the GitHub link to my fork.  My donation addresses (BTC & BTG) are included at the bottom as an add-on.

I've only had my Jalapeños on it since this morning, but it's already reporting a median ~150% return for the Zetacoin mining it's done.

Freicoin and Zetacoin have blipped above Bitcoin recently, sometimes by a considerable margin.  I have a couple of Jalapeños mining through CryptoSwitcher.

Ran across this while I was checking the price of silver this morning:

http://www.amagimetals.com/blog/2013/08/26/checks-held-long-check-credit-card-fraud/

Nice plug for Bitcoin at the end:

It's been a few hours short of 5 days for me.

CryptoSwitcher itself is written in Python; there's nothing to compile.  A short while back, I had it running on Windows and (IIRC) didn't have to compile anything to get its dependencies set up either.  Just make sure you're using Python 2.7, not 3.x.

Cool.  I'll most likely have another order in by the end of the week...possibly in the next day or two.

In dollar terms, my Jalapeños have already returned ~3.5x what I paid for them. They funded a K16 (which might have gone sideways) and a Bitfury starter kit (still mostly on track AFAIK). I almost have enough accumulated again to add another H-board to the Bitfury rig before it arrives.

This. Email is inherently insecure and should be treated as such. It's not much different than sending a postcard. Adding SSL to some of the connections over which a message might travel doesn't change this. PGP (or GPG) is the email equivalent of stuffing a letter in an envelope before it goes in the mail; it keeps your message secure en route.

If the OP is really concerned about the security of his correspondence with MtGox, he should ask to exchange PGP public keys with them.

Had a run of nine blocks solved in a row yesterday...not bad at all for ~3 MH/s. 

I just opened a new one:

https://bitgem.dyndns.org/

Details here.  I also have a wallet generator and block explorer available.

...and the pool is now up.  Announcement here.

I have a Bitgem pool up and running:

https://bitgem.dyndns.org/

• PPLNS with 0% fee (for a limited time)
• Stratum only
• Email notification of dead workers, blocks found, and some other things
• Fairly comprehensive stats

It's running the PoS branch of stratum-mining-litecoin on the backend and mmcfe-ng on the frontend.  I also have a wallet generator (my bitaddress.org fork) and a block explorer (running CryptoManiac's Abe fork) available, as the other Bitgem Abe instance appears to not be maintained.

I've set up an instance of mmcfe-ng with moopless' stratum-mining-litecoin to get a Bitgem pool running.  One snag I've run into is with mining-income estimates.  The Bitgem block subsidy appears to have a bit more variability than some other coins (lately, it's actually crept up a little bit).  I know that the coinbasevalue entry in the output of the getblocktemplate RPC call is supposed to have the value I want (though it appears off in bitgemd by a factor of 100, but that's another matter), but calling getblocktemplate with no parameters can also return a bunch of transactions (especially with bitcoind) that generates lots of activity.  (For example, while the JSON-formatted output of bitgemd getblocktemplate currently returns only 603 bytes, comparable output from bitcoind getblocktemplate returns nearly 2 MB!)

This makes it look like getblocktemplate can take some options, but I'm having a bit of difficulty puzzling them out to see if I can get it to do what I want it to do.  If I could get it to just return a coinbase transaction without gathering up a bunch of transactions from the memory pool, that should run much faster and would be more feasible to call as needed to get the included coinbasevalue.  Is there some invocation of getblocktemplate that will do this, short of tweaking the *coind config file's block-generation parameters (which would most likely be a Bad Idea on a mining-pool rig)? It looks like sigoplimit and sizelimit might be able to control this, but whenever I try something like this:


the result is no different than without the parameters.  Is there something I'm doing wrong here?

I'm running GitHub master...last checkin was three weeks ago, which is close to the 25 Jul 13 date given at bitgem.info for the latest version.  I'm getting the same warning.  AFAICT, you can ignore it for now as there is no newer publicly-released code.

I'm getting a new pool up and running...will post here when I'm ready for it to go public (just want to verify that everything is working first).  One thing I noticed with the first block pulled in is that the coinbase transaction is bigger than I anticipated (0.36623 BTG in block 17619).  Neighboring blocks have similar transactions in them.  The last block mined on the test pool server (before my database server's power supply crapped out) was 0.34781 BTG.  Looking at the coinbasevalue in a getblocktemplate call, it appears that the actual block reward is somewhere around 100x the stated coinbasevalue. 

I've been trying to figure out a reliable way to get the current reward value into mmcfe-ng.  Submitting a patch to just do a basic getblocktemplate call will generate too much work for the coin daemon (especially for bitcoind) as it gathers up transactions to include in a new block.  Is there something you can pass along with the call to leave off the transactions?

Just got my most recent order in today...some silver rounds (the buffalo-nickel round and the new SBSS "Love" round, which just started shipping Monday) and airtites.  Previously when I had ordered silver and airtites, the rounds were loaded into plastic sleeves (as they usually ship) and the airtites shipped empty.  This time, the silver got loaded into the airtites before it was mailed...a nice touch.  I picked one product that was in stock and one that was coming soon, and the order shipped maybe a day after the "coming soon" item became available. That seems reasonably quick to me.