Some people are hopping to LTC mining whenever it's more profitable, and then back to BTC when difficulty goes higher and it becomes less profitable. Those who mine LTC continuously have to suffer through the periods of high difficulty with less profitability than BTC mining, while the "coin hoppers" maximize their profits all the time. Their effect on BTC difficulty is much less (if at all) noticeable.

Because LTC difficulty has been jumping between 25-45 since BTC reward halved. It seems to always go from one extreme to another. Currently it's at 43 and is falling below 30 in about two days. Then you have a couple days window of high profitability with LTC, until difficulty rises again. It's not exactly hard to figure out what's going on here

I noticed an odd rejected share, using cgminer 2.10.2 & stratum:

Rejected 3fd895f5 Diff 4/4 GPU 1 pool 0 (Work below difficulty)

I only barely understand how share difficulties work, but I was told in #cgminer IRC channel that the target hash for diff4 should be 0x000000003fffc000. My rejected share hash was 0x000000003fd895f5, which is smaller than the target, so shouldn't it be accepted? I'm also aware of the discrepancy between "real" and actually used diff1 shares, which is explained here by kanoi. Could this be a similar problem, meaning that there's a disagreement between cgminer and BitMinter as to what actually is the target for a diff4 share?

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.

I've noticed that if primary pool is down when starting cgminer, it won't start mining there when the pool returns. I'm running 2.10.1 and pools 0 & 1 are stratum. If pool 0 goes down after startup, switching to pool 1 and back to pool 0 works fine. But if pool 0 is down during startup, cgminer doesn't switch to it when it comes back alive. The pool is marked alive and has priority 0, but cgminer keeps mining at pool 1 seemingly forever. This should be easy to reproduce: temporarily block network access to pool 0 with a firewall or hosts file, and then remove the block after cgminer has started mining on pool 1.

Limiting the source port range is a really good idea, so that namecoind won't fail to start. Even if you fix the pool connecting to itself problem, some other program might randomly get namecoind's port. Doesn't namecoind have an option to change the listening port to something more sensible?

In the first paragraph, he seems to be thinking that when SHA256 is likely broken in the next 5-10 years, Bitcoin will be doomed. Two questionable assumptions in there: that SHA256 will actually be compromised, and that Bitcoin can't adapt to some new algorithm. Both might turn out to be true, but I wouldn't count on that.

Oh, sorry for the confusion then. I thought you were thinking that it's fine as it is, when you were just asking if anyone has objections to the change.

I'm very good at being misunderstood and misunderstanding others myself!

That's right, I even tried to demonstrate it with my example, but I believe Inaba somehow still misunderstood what I'm asking. I agree that the terms we're using here are not very well defined, for example what does "actual shares" mean to different people? I thought terms like "total amount of work done" would make sense to a pool op.

At least this part should be unambiguous: "If I have submitted 1000 diff1 shares, 1000 diff2 shares and 1000 diff4 shares, it doesn't make much sense to tell me that I've submitted 3000 shares."

I feel like you don't really understand what I'm saying. I want to see diff1 shares in that column, because that's the actual measure of work done. I thought you would understand that as a pool op. It's currently showing the raw number of shares, which is very uninformative when the difficulty of those shares is not known.

I mean the total amount of work that's actually used in reward calculations. If I have submitted 1000 diff1 shares, 1000 diff2 shares and 1000 diff4 shares, it doesn't make much sense to tell me that I've submitted 3000 shares. Total accepted difficulty in this case would be 1000+1000*2+1000*4=7000. Or 3000 shares times the average difficulty of 2.333, just in a more useful format.

That sounds indeed strange, but I can easily replicate it with netcat. nc -p 1234 localhost 1234. I can connect using whatever port, and netstat shows only a single socket, not two like localhost connections usually require. Interesting!

Can't you work around that by detecting this condition in the pool code? Perhaps by checking if there is a corresponding receiving end socket, using netstat or whatever syscalls netstat itself uses. Obviously I don't know what it looks like or even how customizable it is for you, just thinking aloud.

Or you could limit the source port range that you're using, so that the destination port doesn't get picked up.

EDIT: I found a conversation with a good fix for this problem: http://stackoverflow.com/questions/5139808/tcp-simultaneous-open-and-self-connect-prevention. Here's the relevant part: "Bind the client socket to port 0 (system assigns), check the system assigned port, if it matches the local server port you already know the server is down and and can skip connect()."

Looks like it's down / unstable again.

Here's how the shares end up to pool 3, the only getwork pool, when primary pool connection drops:

[2012-12-16 18:14:05] Accepted 0b30f6dd Diff 22/4 GPU 0 pool 0
[2012-12-16 18:14:32] Accepted 1717f2fd Diff 11/4 GPU 0 pool 0
[2012-12-16 18:16:02] Lost 2 shares due to stratum disconnect on pool 0
[2012-12-16 18:16:37] Accepted 481563e1 Diff 3/1 GPU 1 pool 3
[2012-12-16 18:16:52] Accepted 3752b425 Diff 4/1 GPU 0 pool 3
[2012-12-16 18:16:53] Accepted ed86b60d Diff 1/1 GPU 0 pool 3
[2012-12-16 18:17:02] Pool 0 http://mint.bitminter.com:3333 not responding!
[2012-12-16 18:17:02] Switching to http://us1.eclipsemc.com:3333
[2012-12-16 18:17:16] Accepted 33ec2056 Diff 4/1 GPU 1 pool 3
[2012-12-16 18:17:24] Accepted 3c342f03 Diff 4/1 GPU 0 pool 1

Some shares go to pool 3 before cgminer switches to my first backup pool. This also happens during startup, but it's only a share or two.

"Lost 2 shares due to stratum disconnect on pool 0" happens because stratum can't handle disconnects currently, right?

Knowing the amount of shares I submitted during a round isn't useful, when the shares have dynamic difficulty. For example, some shares may have been submitted at diff 2, others at diff 4, especially if my hashrate isn't constant. Total accepted difficulty would be a more meaningful stat. You already calculate this in a similar way on the "Diff1 Shares (Actual)" column - I presume the number in parentheses is the number of shares accepted, while the bigger number represents total accepted difficulty.

"My Shares" column in block history is displaying the amount of shares submitted, which is not very useful when using vardiff. It should be changed to show the combined difficulty of those shares.

I've noticed two problems with stratum backup pools, that still exist on 2.10.1. The bigger problem is that stratum backup pools can become permanently dead. This is only happening on my rigs with wireless connections, so maybe it's a problem with latency / packet loss? Second problem is that with failover-only disabled, most leaked shares seem to go to my getwork backup pool, even though it's last on the list. I have two stratum backup pools with higher priority than the getwork pool, but they rarely (if ever) get leaked shares. This is only a small matter, since share leakage is very low.

Did you download 2.9.7 or 2.9.7-1? The latter has a Windows crashing bug fixed.

PPLNS should be one of the easiest hopping proof methods to understand. It's basically the proportional payout system, but each share can be rewarded on multiple rounds.

A proportional pool counts shares separately for each round, and when a block is found, it pays out the block reward (minus fees) to miners proportionally to their number of shares in that round. Then everyone's share count starts from zero for the next round, as miners begin working on the new block. This method can be exploited by only submitting shares during the beginning of each round (when everyone has very low share counts), and then stopping at a certain calculated moment, if a block is not found by the pool.

A PPLNS pool also pays miners proportionally to the number of shares submitted when a block is found, but it doesn't reset share counts after each block. Instead, it always keeps account of the last N shares, which is usually something like 10 times the current difficulty. This means that a single share will quite probably be used in reward calculations multiple times, but the payment for one share is lower on each occasion. This also means that pool hoppers can't exploit the pool by mining there only when other user's share counts are low, because they are never low.

Variance on PPLNS can be lowered by increasing the number N, so that even more shares are used in reward calculations when each block is found. The drawback of increasing that number is that new miners will have to wait longer to get their payments, but they will also keep receiving payments a bit longer when they stop mining.

At the very least, it should be mentioned in the first post(s) that BTC Oxygen is a proxy pool. I didn't know, since it's only mentioned in the second page of this thread. The first posts advertises that "even if a block is later marked as invalid/orphaned your earnings are not affected". That's a bit misleading too, since it gives the impression that you mine your own blocks. I was a bit curious about why there wasn't any kind of block history. Disclosing the pools you use would certainly be helpful in maintaining trust.