I can see that you listed a lot of numbers but I don't know where they came from or what they mean. In particular how did
you determine the expected value? Maybe if you walked through one example it might help understand.

The problem you seem to be seeing is exchange related. If you review the previous reports in the old locked thread you
will see a 20% loss even when the payout coin is the same as mined, ie no exchange. Either there are 2 seperate problems,
both resulting in losing 20%, or you haven't yet zeroed in on the original problem.

I'm not disagreeing that you saw a problem just disagreeing with your analysis of it. Seeing an obvious reference to 20% in
the code is certainly suspicious and deserves to be pursued. In my analysis of that code I can't see how it
results in being short changed at the exchange. That code only is used to display estimates for the pool, it has nothing to
do with the actual trade on the exchnage.

Let me be more blunt. Do your own research, I don't make recommendations.

It's the stratum difficulty. Some pools use vardiff and will adjust the diff automatically, some pools have
special low diff ports, and others allow the diff to be set in the password string. RTFM.

There are many threads dedicated to this topic. I place zero credibility in these discussions. There are 3 types
of advice: from those who don't know what their talking about, from those with ulterior motives, and occasionally some
sound advice. 

It's better to learn than to rely on the advice of others.

However, in general terms coins that can't be mined or can't be mined efficiently with a GPU or ASIC are more CPU friendly.
Your assignment, should you choose to accept it, is to find those coins.

BCH is doomed. It was al all-in bet on replacing BTC and it failed to get a critical mass of mining power.
The hash rate on BCH needed to be high enough to compensate for the high diff to keep miners
interested. Why mine BCH and get 15% of what you can get mining BTC with the same amount of hash?
It's only a matter of time now.

It's like a spinoff from a corporation. You cut out a piece of the business and give each shareholder of the parent
company shares of the new spinoff company. This results in a smaller parent company so it doesn't come out of nowhere.

The success of the spinoff is determined by the combined market cap of both companies. Unfortunately in this
instance the market cap of BCC/BCH is distorted by the inability to deposit new BCC/BCH to any of the exchanges.

Unlike in the corporate world this spinoff was not firendly. I's actual intent was to replace BTC, essentially becoming
a takeover. The amount of the parent company (BTC) spun off is determined by miners. More miners swicthing to BCC/BCH
means a bigger chunk of BTC capital gets moved to BCC/BCH.

Again the main metric is the sum of both market caps, as long as both are trading freely. Considering the trading situation
of BCC/BCH at this time it's impossible to determine a realistic market cap for it.
determine how big the BCC/BCH piece is.

Are these hash rates for real? BCC almost as much nethash as BTC and still no blocks???

https://pool.viabtc.com/

Can difficulty change mid block? If not we have to wait for the current block to be solved.

You're just assuming that $market forgets its current value when updating. That would result in a consistent
80% value but this would only ocurr if $market is a local variable. A global wouldn't lose its value between
iterations of the same function. And "out of scope" just means there are two copies of the same variable name
in a different scope. The reference in any single function will allways be in scope.

I think you've latched on to this 20% code and just assumed it is the source of the problem.

You also overcomplicated my test. You just need to follow one block on zpool from creation to credit to your balance.
All of the raw data is there, share%, coin amount, BTC value. The BTC value can be expected to fluctuate with
exchange price. The last BTC value displayed before exchange should be very close to the actual exchanged value,
Simply confirm that the expected amount was credited to your balance.

Many thanks.

I think this is what I was getting at in my previous post. I assume your BTC and BCH wallets use identical keys and
have the same set of addresses created before the split yet work fine side by side?

It's impossible to keep up with the posting activity but I hope this question doesn't get lost.

I'm curious about the instructions to move all BTC to a new wallet. Is this simply a way to ensure
BTC and BCC don't use identical keys going forward or is there a technical reason for it?

I ask because if users do nothing they are in that situation already. They have BCH that can be accessed
by their BTC keys imported into a BCH wallet. If BTC need be moved in order to claim the BCH shouldn't that be
the case also if abandoning the BCH. After all it still exists.

If there is no technical need to move BTC to a new wallet with new keys the only issue is the existance
of two currency wallets sharing the same keys. Since I own the keys to both what is the security risk?

Edit: changed BCC to BCH.

One additional point. If the BCH is claimed as described in the OP wouldn't the old BTC wallet still exist
and be useablewith the original keys?

Ok another point. The original keys are associated with the same addresses on both currencies. IF BCH keeps
the original keys it will also keep the original addresses from the BTC wallet. It might be desireable to keep
your existing BTC addresses as BTC addresses and obtain a set of new addresses for BCH. To that end would
the following process achieve that result?

1. Create a temporary BCH wallet using the existing BTC keys.

2. Create a new permanent BCH wallet with new keys.

3. Move the BCH from the temporary wallet to the permanent wallet. The temporary wallet can then be discarded.

4. Continue to use BTC with the original keys.

I don't agree with your analysis.

A zero value in AverageIncrement would most likely occur on a failed exchange query and only assuming
there are no error checks. In such cases a zero bid price is possible.

This would cause a 20% drop in the value of $market->price in the current sample.

In the next sample we would adjust based on a new bid price. If a second failure occurs $msrket->price
would become 80% of 80%, or 64%. Each successive failure would reduce the value more.

If the following samples returned a valid bid price the value of $market->price would gradually correct itself.

There is no way to maintain a consistent 20% penalty.

Did you do a test as I suggested?

cpuminer-opt-3.6.8 is released.

Fixed timetravel10 algo.

git: https://github.com/JayDDee/cpuminer-opt

tarball: https://drive.google.com/file/d/0B0lVSGQYLJIZQTc3OGFmUzVONTg/view?usp=sharing

Windows binaries: https://drive.google.com/file/d/0B0lVSGQYLJIZb0J1YmY4alNQRDg/view?usp=sharing

Binaries are not avaiable on git.

I have seen no convincing data in this thread for either case. Several people posted demonstrations
in the old thread with and without exchange. I abandoned zpool when crackfoo dismissed the problm
out of hand without investigating.

The simplest way to see it is in the graph. Best to choose a pool with only one
coin and a long enough TTF for each block to be clearly visible in the graph. When a matured block is credited to
the balance (status changes to "cleared") there is a visible drop in the total unpaid. The total should not
change significantly when moving from pending to balance.

More detailed tracking can be done by monitoring the value of a particular block. Do the math based on block
reward, % share and exchange price to confirm the pending value. Note the last value prior to exchange and
compare with the amount added to the balance.

Under normal mining condoition visible drops in total unpaid that always coincide with a balance credit could be a sign of the
problem, if it still exists. I've only done a litle bit of mining on zpool recently without specifically testing for this
problem and didn't see anything alarming.

Oops, that's what I get for skim reading. Still 75C is not that hot, and an overheated GPU won't cause a system shutdown.
Either the power draw between the PSUs is unbalanced and overloading one of them or one is defective and can't handle
a normal load.

There are a few things that can be done to troubleshoot and isolate the suspect component. Split the rig and try running it
with 5 cards and the big PSU, then try running it with the other 3 cards only using the second PSU. Swap cards with the other
rig. Swap PSUs. Just move components around to see if the problem follows.

A lot of people get that wrong. A hotter card on ceartain algos means the cuda cores are working hard and aren't waiting
on memory. That's a good thing, sort of. Such compute intensive algos are easy to implement in ASIC. The only thing
preventing it is demand. All of these algos that reshuffle sha3 functions are likely to get ASICs eventually if the coins that
use them are successful.

Moving from CPU to GPU to ASIC improves compute performance by orders of magnitude, compare a CPU with 8 cores vs
a GPU with 2000. Memory capacity and bandwidth can't keep up with the number of cores on a GPU so on algos that are
memory hard the cores sit idle much of the time waiting for data from memory, and consequently run cooler.

It's power, the temps are fine. The 1060 is rated at 120W and you have 8 of them and the rest of the system powered by a 1000 W PSU.
Pull 2 cards from each rig and build a new rig with them or replace the PSUs with a pair of 1600 W beasts.

cpuminer-opt v3.6.7 is released.

Added Skunk algo, Tribus a little faster and a little code cleanup.

Source tarball: https://drive.google.com/file/d/0B0lVSGQYLJIZOTZBNHNHU0h2N0E/view?usp=sharing

Windows binaries: https://drive.google.com/file/d/0B0lVSGQYLJIZRHVlV3dFZnowNEk/view?usp=sharing

Fans are cheaper to replace, it's as simple as that for me.