Thanks for refocussing my thinking. Your suggestion presumes a pre-existing bug
causing incorrect sharediff and my fix was the second wrong that made things right.

The more I think about it the more plausible it seems. I had assumed the sharediff was correct,
but it's never used except for user info so an error would have no side effects.

I've got some work to do.

Run as different users, that will automatically choose unique datadirs.

Running different versions won't do it, both will use the same datadir by default.

+1,

A high default starting diiff can be tolerated but the bigger problem is the minimum diff is too high for
a single GPU, even worse for CPU. The ability to set a lower starting diff or automatic adjustment
to a reasonable diff would be greatly appreciated.

I'm an altcoin guy but this question applies to bitcoin.

The formula for converting share difficulty to an equivalent number of hashes
is documented on the bitcoin wiki: https://en.bitcoin.it/wiki/Difficulty

However, in my testing this formula produced incorrect results for altcoin algos.
I couldn't test sha256d as I don't have HW capable of supporting the extremely
high stratum diff. But since most altcoins were cloned from bitcoin I see no reason
why sha256d/bitcoin would be an exception.

Following are the comments I added to my code to explain my modification.
I arrived at the value through trial and error. Averaging over 100 shares the results
converged nicely to the miner's calculated hash rate for a cross section of algos.


Although the numbers work I have no explanation for the discrepency with the documented
formula. I chose to decrease the denominator by a factor of 4 but increasing the numerator
would have the same effect so I don't know which one is "in error".

Is it simply a documentation error or am I missing something?

Sigh!

You misunderstand, you can't choose the merged coins, the coin devs do. One coin is primary and you mine
that, Any coins merged with it also receive your hash.

Merged mining is only supported for coins designed for it.

The available parasite coins are always listed at the bottom and always have hash assigned to them.
The hash display is gray to indicate merged hash.

In most cases you can identify the host coin because the hash rates match, but scrypt is more complicated
because there are multiple hosts and multiple parasites. It would be nice to be able to identify which
parasites merge with which hosts.

I've been trying to follow but I'm lost. I can't figure whether you're compaining about
allocating hash to coins in the multipool or merged mining. They aren't related.

A clear problem definition would help.

yaamp/yiimp has had merged mining for a long time. Take a look at scrypt, all those coins at the
bottom of the list with the hashrate in gray are merge mined.

The wallet accepts hash generated using the truncated pers string so it's not a miner issue.
That pers string is now part of the POW specification for the coin. Changing it now is changing
the specification.

Having a seperate parameter for the pers length is bad design. It is not necessary, strlen works fine,
and just creates opportunities for errors, as happened here.

It's a coin issue, there's nothing for me to fix.

You need the correct parameter values, ask the coin's devs.

Edit: Actually the real problem is too funny. The litb miner screwed up the key length:


The string is actually 75 chars but the length is hardcoded at 73. This means the key is actually the first 73 chars of the string:

If someone wants to mine 50% solo and 50% shared they can split their
hash accordingly. I prefer to keep the pool egalitarian, it's less like a lottery.

Just my opinion.

An extension of that is that mining requires a constant supply of energy, and solar alone
can't provide that.  Either the mining equipment sits idle at night or the system requires
batteries for storage. Either reduces the potential for profit significantly.

Solar power works best when the energy can be stored cheaply in a different form,
or when it's consuption can be scheduled to coincide with generation.

Copy & paste the entire key including the quotes.

cpuminer-opt-3.9.7 makes changes to command line options.

-R is no longer used as a shortcut for retry-pause, users must use the long option.

New options have been added to facilitate mining algos based on yescrypt or
yespower with different parameters:


These parameters can be used to mine existing algos or new algos.
Existing algos may still be mined using their original unique name without extra parameters.

Any new algos based on yescrypt or yespower which only differ in parameters can be mined immediately
without requiring a new release of cpuminer-opt by using the generic algo name and specifying the parameters.

For example the recent cpupower algo can be mined using the following parameters:


Edit: Be carefull with the key, it's very long in this case and contains spaces and special characters, the quotes are necessary.

Parameter values are determined by the developpers of the coin and/or algo and should be listed in the coin's specifications
or mining instructions. Cpuminer has no knowledge of the parameter values except for algos previously
defined with a customized name.

Only the N parameter is supported for scrypt, R is harcoded with 1.  -a scrypt -N n has the same effect as -a scrypt:n.

-R option is deprecated

Plans have accelerated. There will be no grace period which would delay new features.
In the next release -R will have a totally different meaning, there will be no warning message.

I Initially declined to include cpupower algo in cpuminer-opt due to a number of  concerns.

Algo bloat: the number of supported algos is now around 100, that's 100 different
options for the -a argument. Many are almost identical with only parameter differences.

Single coin algos: I want to avoid algos that are tied to one specific coin and unlikely to be
used by any other coin in the future.

Algo branding: I prefer generic algo names instead of names that are closely associated with
a single coin.

Planned obsolescence: Coins that have plans to change algos are more work to support.

Unfortunately cpuchain/cpupower hits on all those points. The devs have expressed a desire
to maintain a tight coupling between the coin and algo, objected to a generic and more
descriptive algo name, and have plans to change algos.

All these factors led me to conclude the algo did not have much of a future and would likely
become obsolete.

Given the level of control the devs wanted over the algo I suggested it would be better to have
a dedicated cpuchain miner where the devs would have total control and freedom over their
algo of choice.

The existing cpuchain miner is forked from cpuminer-opt and can easilly import any missing
optimizations.

I'm looking at ways to simplify support for multiple algo variants to reduce the bloat and provide
some forward compatibility with new variants that don't require code changes.

This is a heads up for a proposed user interface change to cpuminer-opt.

I am intending in the next release to remove -R as a shortcut for the --retry-pause option:


I have plans to use -R for something else, --retry-pause will still be avaiable.
Retry is a rarely used option as most users prefer to exit and failover to a backup
pool when a connection is lost.

Until -R is repurposed its use will produce a warning message.

https://github.com/JayDDee/cpuminer-opt/issues/206

If you can't be bothered to read the instructions I can't be bothered to help you.

Both your posts make no sense, cpuminer-opt will not compile with VS.

Both of you RTFM!