Cool thanks - I haven't had a chance to try it out yet. Emre, can you get an FTP login space setup for hog? If we get a download link and some instructions setup, people can start testing it out.

Why does yvg1900 not open source CPU miner?! Is it greed? OH YES. ABSOLUTELY YES.

On the contrary, I think he has been extremely generous. Here at MemoryCoin, we're trying out the crazy idea that developers can be compensated and rewarded for the work they do.

His fee could be 25 times higher and it would still make sense to use his miner.

Bounties do have a place. Where there's a well defined project of limited scope, or an intractable bug, bounties can work well. However, a lot of the projects we want to support aren't like that.  Often we're trying to encourage not just development, but on-going code maintenance and service provision.

I've looked at, and participated in the bounty incentives that 3I is setting up. I can understand the theory behind it, but ultimately I found it to be a demotivating and dehumanizing process as it reduces people to 'units of production' chasing carrots. I don't think it's the best way to motivate and energize highly skilled, highly creative talent.

I think a better model is to make clear the kind of projects we're interested in supporting, and then to recognize and generously reward people who create value.  It requires trust and diligence, but wastes a lot less effort and feels better from both ends when done well. I think it has the benefit of attracting people who have an interest in the projects and who are therefore more likely to create long-term value.

1) Was this put to a community vote?  This seems like one of those issues that we should have a formal community process for...like officers propose an amendment, assign a voting address and a voting window, community members & officers vote, officers store vote/address results independently in another blockchain to prevent future manipulation and allow independent verification...like maybe datacoin?

No, rather this change was requested in order to allow community votes. I wasn't expecting it to be contentious. For future issues where we need broad consensus and a mandate, I think a community vote would be appropriate. Don't think we need an independent blockchain - our blockchain is perfectly secure, all the coins depend on it.

2) Tx fees aren't much right now, probably won't even be noticed.  And I know it's only an optional zero fee, but some users will choose it.  I know other coins have changed tx fees, but MMC's long-term outlook - economics, ability to meet manifesto, effect on current price, etc - should be much more sensitive to network transfer fees than other coins, and so should be given more review.

Even an option for zero fee means an impact on future long-term network revenue.  And even changing fees creates future price uncertainty by signaling that monetary policy can change arbitrarily.  (A formal community review and voting process would counter that...)

You're overthinking this a lot. My view is that transaction fees in other coins are really broken and we'll likely be the first coin to do it right. At the moment transaction fees are 99% a usability issue.

We just sent a strong market signal to value MMC relative to future fiat (i.e., network energy costs), rather than relative to future BTC/other cryptos.  MMC market volatility should increase in the short-term as beta with BTC/USD moves to unity.

3) Long-term, if you assume the MMC "product" is voting on the blockchain, and the cost of a vote is a tx fee, network revenue approaches network tx fees.  Especially as block rewards go down in the future.  Long-term, margin between network tx fees and electricity costs gives market incentives to mine and provides economic empowerment to meet the manifesto.  We've now reduced long-term mining margins, incentives, and empowerment. 

My view is that (in the long term) transaction fees should be related to cost of processing, applied to every transaction, and not require any action or decision from the user.

Not sure if troll or not - maybe he picked something up from another wallet and is blaming MMC.

What might be cool is to apply the crazy memory intensive 50 something passes to the address generation transaction/encryption.

That way generation of rainbow tables becomes way harder. Not sure if there is merit in that as it will only slow it down linearly v.s. stronger passwords being exponentially harder to guess.

Yes - I think this would be technically superior, but I'm not sure we want to create a multitude of ways to convert passphrases to memorywallets - it might get confusing.
It would be a linear improvement, but a huge one - maybe 10 billion times more secure, so maybe we should. It's a good idea.

I've been doing some analysis and tweaking this morning.

Test machine and i7 3770 with 8GB

This has 4 real cores and uses hyperthreading for 8 virtual cores.

I'm finding that most of the performance (~85%) is achievable with only 4 threads - assuming those threads are maxing out the AES-NI instructions.

Mining with the other 4 threads is not efficient - it's better to use those to mine another CPU coin that doesn't require AES-NI - ProtoShares or Primecoin are good candidates.

I've just tested ProtoShares, it does impact the MemoryCoin HPM, probably because of contention for memory.

Total figures I'm seeing on the i7 3770 - 8GB

MMC - 5.2HPM 
plus
PTS -  115CPM

This is in contrast to just running MMC exclusively - which gives about 9HPM
Might see less impact on MMC mining if using the remaining cores to mine a non-memory intensive CPU coin like Prime.

Okay - tested a Prime miner - using the non AVX version gives better results, so I'm thinking the contention is not for memory, but instruction set - Here's the figures

MMC - 6.2 HPM
plus
XPM - 14,000 PPS

- This might be a good combination of coins to mine on the same machine