Sounds like you're running a trading bot and are angry because you're encountering weird bugs. Guess what, normal users might not be affected enough for it to matter, certainly not as much as you're trying argue. Let's take my case for example: I've executed 1317 transactions on Bitstamp, totaling $1276.26 in fees. If Bitstamp really added an extra 0.01 to all those transactions, they've stolen $13.17. That's 1% of the fees I've paid. I can see this being a problem, if you are a spammer of 0.01 BTC trades.

BTW, who is the 'spammy fuck' now?

EDIT: I can see the rounding problem in my fees easily, it just doesn't add up to very much in the end. Only ~20 of my 1317 transactions were smaller than 2 dollars.

That's done to reduce the delay in payments. A 1.5% donate is required for the prepay perk, which pays for blocks instantly (and also pays for orphan blocks). New users have had trouble understanding the combined delay from block confirmations and PPLNS.

An orphan block reduces the DGM score without generating any payout, but a stale block doesn't, right? Since you are submitting blocks to multiple bitcoinds, the boundary between orphan and stale blocks is not that clear, when some bitcoinds can still accept a block while others would reject it. Since this distinction is affecting scores, it would be interesting to have more detail about how you decide whether a block that didn't pay was orphan or stale.

The extreme, malicious case would be running one bitcoind behind a crappy dial-up connection. It would almost always accept blocks that all the other bitcoinds would reject. A bigger than expected portion of blocks would be marked as orphans instead of stales, resulting in smaller scores for users. On the other hand, if you are running, say, five bitcoinds without any malicious intent like described above, and only one rejects a block, why should that block be marked stale? Isn't there a good chance the other bitcoinds could still spread the block and make it win the race? And surely the pool should attempt to use their own block as a base for the next one they are working to generate.

Actually, I have wondered why pools don't modify their bitcoind to not reject a block, if the earlier block of same height still has zero confirmations. Why not work on the block the pool found, even if the other block of same height is already widely spread? If the pool happens to be lucky enough to mine a second block before the competing block gets a new confirmation, their earlier stale block combined with the new one would net the pool two blocks instead of one. Surely I'm missing some obvious reason not to do this.

I think Ripple (XRP) would be a good addition.

Speaking of the API, does anyone know how it works with two-factor authentication?

Mining is affected now, lots of short outages ATM.

Run a separate instance of cgminer for each coin, and make a script that uses the API to enable GPUs on some instance, and disable them on all the others.

Assuming normal luck all the time, you will never reach 100% expected payout while mining. That's because of the delay in PPLNS, and the delay in block confirmations if you disabled the prepay perk. You will only reach 100% expected payout after you have stopped mining and received all the delayed payouts. This delay is pretty close to 1 day if you have the prepay perk disabled. I heard it's enabled by default now, though.

Ripple deposits & Bitstamp codes.

I'd wager a lot of CoinChoose users couldn't care less about the fate of any altcoins. They only want as many bitcoins as possible, and then some more.

I believe a block is marked stale if it gets rejected by BitMinter's bitcoind. That could happen if the server that's handing out work tries to submit a block without being made aware of a new block just received by the bitcoind. That delay should be very small, but it's still something. Latency between the work server and actual miners is obviously bigger. If a miner submits a block that's known to be stale by the work server, the server should just discard the block without trying to submit it to bitcoind. Do those kind of blocks get marked stale, too?

An orphan block gets distributed to the network at least partly, until it's later abandoned because some other block minted at roughly the same moment got distributed faster or just got plain lucky. A stale block is totally unseen by all nodes.

If you are using cards that support ULPS, disable it. Latest MSI Afterburner has a convenient checkbox for doing so. That's exactly what happens when the display is powered off on an ULPS-enabled card.

Also, with a 2x7970 Crossfire setup, I had to disable monitor power saving totally, just disabling ULPS didn't help there.

There have been a few outages today, lasting only a minute or so. Works ATM.

15FstWqNAaZPUx7WTCSqoFUtCEotptg7bD

Try harder.

So, everyone is getting ready to fire up their Amazon server clusters again?

Does it work so that every input can turn out to be either valid or unspendable, and you can't know which until you try to spend it? I'm sure that would be useful.

Looks like you have misunderstood PPLNS (in a very common way), if you indeed believe that randomly hopping on/off a PPLNS pool would decrease your expected payout per share there.

DevCoin was added to the mcxNOW exchange, so trading DVC isn't confined to just Virucrex anymore. I think one problem might be that BitMinter is too big to not immediately takeover DVC or IXC if merged mining was enabled. BitMinter already has over 50% of the NMC network hashrate, and if enabled, it would be about 90% of the DVC network and an even larger majority of the IXC network.

It was funny how other pools proclaimed NMC as a dead coin and dropped the support. If they had kept merged mining NMC, it wouldn't be in this situation now. Seems like a self-fulfilling proclamation to me

2 to the power of 16, or 65536. So for example current LTC difficulty of 605.526 is reported as 39.7M. BTW, CoinChoose is still showing a diff of 596.88735373 for LTC.