4-5 significant digits should be enough for each coin.

I would like to see these stats excluding the bets of cici/nakowa/celeste.

CoinLab Protected pool was the pool where you could earn those loyalty points last year. The Redeem pool is for redeeming them. I presume Chris meant that the protected pool will return to 95% PPS again. However, we still haven't heard anything about the 90 days expiration rule that sneaked it's way into the first post. Have some users' points been expired because of that rule?

OP wins, obviously.

The wallet you initially create on one machine is filled with 100 keys. If you copy the same wallet to other machines, they will use those same keys. When one machine generates a block, the other machines pick it up from that block since they have a key for the address where the block reward went to.

Just copy the same wallet.dat file to each machine. I think that might cause problems if you have blocks generated to over 100 addresses. Then the pre-generated pool of keys might run out and new keys would not be the same on all wallets. A deterministic wallet wouldn't have this problem, but I'm not sure if it's deterministic or not.

Is mining Primecoins somehow against their terms of usage? If not, they really are calling the wrong people idiots when dealing with this 'attack'.

It's the worker dashboard from BTC Guild.

Or just allow users to select their favorite column, and sort by that when page auto-updates. Maybe store it in a cookie.

Also, contrary to what many people seem to believe, Google Authenticator requires no communication with Google. The device that carries your codes could even be offline, if you can keep it's clock synchronized accurately enough.

If you don't trust Google Authenticator (which by design has no reason to communicate with Google), the algorithm it uses is completely open and you can implement it yourself. But I think someone would have already noticed if the application was secretly doing network communications, when it has no reason to do so.

It's true that some sites offering 2FA use the QR code drawing service of Google, and that really doesn't help in making people understand how the system works. Since in that case the code IS coming from Google, it's only natural that people assume Google is somehow unavoidably involved in the 2FA process, no matter how it's implemented. Obviously the proper way is that sites draw the QR codes themselves, instead of using an external service and leaking codes in the process.

My confirmed LTC balance is suddenly negative (-0.2182).

I don't completely understand the implications myself yet, but I had a vague feeling that time-based PPLNS had some problems, and the PPLNS thread seems to confirm:


Now that I'm actually mining on a pool which uses this method, I might give it more thought, and perhaps understand the problem. Not a lot of money at stake here, and I don't mind being motivated to do some research

Shift-based PPLNS would be the best PPLNS implementation based on that thread. It's used on BTC Guild and BitMinter.

The unavoidable latency between issuing a work restart and a miner receiving it results in a small window where the miner is effectively working to produce stale shares. Some devices (like BFL ASICs) also have additional latency on restarts, but let's ignore that. The latency window is always the same, no matter which share difficulty is used. If a miner is using diff16 shares, the probability of producing a stale share is twice that of another miner which is using diff32 shares. Not the same, as you are implying in the bolded part of what I quoted.

Reducing share difficulty makes it more likely that stale shares are produced during block changes, because the chance to produce a share that matches the target during the latency window is higher. But since all shares have lower value, expected total stale difficulty is the same.

There is a pool that always tries to mine the most profitable coin. https://www.multipool.in. That being said, you could also use CryptoSwitcher to setup a similar port forwarding service yourself, and pick only the coins that you want to mine. There's nothing forcing you to touch the miners when a coin change is triggered in CryptoSwitcher, you could just as well change a port forward to point to a different pool or coin daemon, and always keep your miners pointed to the port that's being forwarded. Just like multipool is doing it.

Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used.

Pool hopping.

It's worth noting that 'dooglus' with the same real name has had a definite online presence well before the beginning of Bitcoin. It's a rather well thought out scam, if he indeed did create a false online personality for scamming purposes before Bitcoin was invented.

You're welcome, kakobrekla.

I'm often seeing stats with zero accepted shares and lots of invalids on some coin. My miners report accepted shares, obviously with some rejects during block changes. I'm also getting paid, though it's a bit hard to say yet if I'm getting the correct amount for my hashrate. The share stats just look really messed up, and are rarely updated. For example, my FTC stats have been stuck at 50 invalids and zero valids for a while now, even though I'm getting accepted shares in constantly.

Do the hashrate graphs include rejected/stale shares, or are they based on just accepted shares? It would also be great if multiport users could view a combined graph of their hashrate.

Also a question to miners here: are you using any backup pools in cgminer/bfgminer? I'm thinking of adding a LTC backup pool, but cgminer README warns against using on multiple blockchains at the same time. Previously I thought that would mean even the multipool concept wouldn't work, but clearly that's not the case. Maybe it's still a problem with backup pools?

Unless I'm mistaken, confirmation emails are only sent when you withdraw USD or BTC. That should deter most attackers, since they can't directly steal anything if they have access to the account.