Block: 00ecb8669cd08eda...  Diff:11.2M  Started: [16:49:43]  Best share: 70.2K

It's also listed in the "coin" API call reply.

For scrypt, cgminer does a conversion by multiplying all difficulties with 2**16. That's why those values might not look right.

The difficulty reported by terracoind (which I guess is what cryptocoinexplorer uses) is not for the next block to be generated, but for the last one already generated. AFAIK only cgminer/bfgminer show what the current difficulty is. That difference doesn't matter much with bitcoind, but with terracoind the reported difficulty is very often lagging behind since it changes so often. Not really relevant to CoinChoose since you are smoothing the graph anyway, but for someone setting up a hopping script, this is a way to optimize it.

Good decision. It was making the other graphs hard to read

What's the problem with using Google Authenticator? It has nothing to do with Google accounts, and is very easy to implement. I even added it to my own ssh server.

Is anyone else getting a broken graph on the front page, with the bottom being -50 USD? I don't think we'll ever go that low, so why not hardcode the bottom to zero instead? The price does look more stable now, though, so maybe the negative bottom is intentional

Judging from the latest posts, it looks like forum messages are sometimes almost as hard to correctly understand as payment methods.  

I guess it would be possible to drop the libcurl requirement if both getwork and GBT could be disabled, right?

I'm sure you premined at least a couple trillion! SCAM ALERT!

Vircurex is now up and trading continues with both DVC & IXC. DrHaribo, please save us profit-seekers from DGM! I would much rather mine on a PPLNS pool.

I think CoinChoose is trying to a show a readable chart on what the profit levels would be if someone mined TRC exclusively. The more profitable way to mine TRC is to hop the chain when difficulty falls below some threshold level. I'm currently hopping TRC with a custom script, my rigs are running two instances of cgminer and the script constantly decides on which instance the GPUs are enabled. USB devices might not work with this scheme, though.

Yes, please add 2FA! But how would OpenID be connected to that? I'm usually just annoyed by sites that want to rely on OpenID or Google accounts and not have their own account credentials. Separate credentials + 2FA for each site is much better and simpler IMO.

I would really like to hear some proof that DGM indeed works that way. I don't feel 100% confident that it's fair in that case, but haven't seen any real proof that it's not, either. It might definitely feel like you are losing expected payout when abandoning a round, but unless you have proof that DGM works that way, I'm more inclined to believe that the opinion is just based on a misunderstanding.

The huge failure of DGM is that it's almost impossible to understand (I mean really understand, not just on the "capacitor is being charged" -level ) if you aren't a hardcore mathematician. I'm far from that level myself, and thus Bitparking doesn't feel as attractive anymore. Then again, even if you can understand a pool's payout method, it's another thing whether they have implemented it properly...

Vircurex was the only place to trade those coins AFAIK. IXC was added back after the initial decision to remove it, but maybe only the removal was announced on twitter?

I'm under the impression that you should have no reason to think like that. In a fair payout method, all shares should have the same expected payout, and not depend on history at all. With DGM (and most other methods as well), the actual payout per share will have lots of variance, but it should average out after a long enough time, even over multiple accounts that are mining only occasionally.

DGM is really hard to understand, and unlike with PPLNS, I still haven't grasped it well enough to be 100% sure of the above. However, it would be a very lousy payout method if miners were forced to stay on the pool to not lose their expected payouts.

Now, if you just added DVC & IXC merged mining, Bitparking miners couldn't claim that they are earning more than Bitminter miners.

Of course, throwing 12TH/s at those chains would disrupt the status quo a bit.

That's quite low. I'm getting almost 50kh/s per thread with an i5-3570.

It's working, but I'm getting less than half of what's produced by the linux version. 25kh/s vs. 60kh/s per thread on a 2500K. And I'm actually running the linux version with VirtualBox, so it might be even faster when run natively.

EDIT: This post might be relevant to the speed difference: https://bitcointalk.org/index.php?topic=196196.msg2082435#msg2082435

How did you manage to compile it without errors? That might be useful information in case of future problems.

Good to know, I guess I shouldn't expect every commit to work perfectly in marginal cases like cross-compiling.

EDIT: I saw some new commits and tried again. Now it works.

My cross-compiling setup suddenly fails on the newest git master version. I get multiple errors about sys/socket.h not being found. I traced the problem back to commit 31aa4f6cebc51e26b349606fd78d71954bda87da. Commit 657e64477b75603bc9b08eed425bc47f606814cb and everything before that compiles correctly. Is there a new dependency that I'm now missing, or is this a bug? The only sys/socket.h I have (/usr/include/x86_64-linux-gnu/sys/socket.h) is not under my mingw toolchain, but that wasn't a problem when cross-compiling until now. For reference, here are the files in my toolchain: http://pastebin.com/sSEqFL63