Exiting because of faulty parameters for me - seems like memory size is being sent as 6912 . . . not divisible by 1024 and YAM rejects it.

Yeah - Middlecoin for CPU coins, payouts in MMC.

Hmm strange on another box i can run 8 threads with 1gig of memory. So I'm going to tweak the auto mode to take care of the cpu threads at maxed memory size.

Sounds like a good plan - the new 'm' parameter is the max amount of memory to use, btw, not per thread.

It's back now - for comparison, my gmail was down for a few hours yesterday - these things happen.

Lot of coins have this problem, this could be special if built in the protocol.

Don't think there is any way to build this into the protocol. Big pools could just pretend to be small ones.

What we're looking at, at the moment, is implementing p2pool - hopefully building it into the GUI.

We need new miners - pro at specific pools, new at all pools - and services for both.

I saw liveCD, the new mienr guide, etc. What's our newest stuff to broaden user-base? 

I'm thinking a new project that would broaden the user base would be a program (MSI/GUI interface) that identified the most profitable current CPU coin to mine, and switched between CPU coins as profitability changed, and sent all funds, as received, to a MMC exchange gateway. It would need to be closed source, and bundled with all necessary miners, and zero-config, as always.

I figure our audience is something like people with +$5K and > 6 months in coins. 

Yes, very much agree - we should assume fluency in Bitcoin.

I think we need to communicate our improvements over Bitcoin - mining/transaction processing distribution (CPU Coin) and paid development team.