Configuration file structure
Let's start by giving an example of a fairly more advanced config file, demonstrating some/most of the functionalities.
{
"pools": [
{
"url": "stratum-eu1.hashlink.eu:13031",
"user": "Login.worker",
"pass": "XYZ",
"diffMultipliers": {
"stratum": 1,
"one": 256,
"share": 256
},
"algo": "fresh",
"protocol": "stratum",
"name": "FRESH-hashlink"
},
{
"url": "birdspool.no-ip.org:3333/",
"user": "omissis",
"pass": "irrelevant",
"diffMultipliers": {
"stratum": 1,
"one": 1,
"share": 1
},
"algo": "grsmyr",
"protocol": "stratum",
"name": "MYR-grsmyr-birdspool"
},
{
"url": "tanukifu.ddns.net:5567",
"user": "wallet+0.0075",
"pass": "meh",
"diffMultipliers": {
"stratum": 256,
"one": 256,
"share": 256
},
"algo": "qubit",
"protocol": "stratum",
"name": "MYR-qubit-USA_E"
},
{
"url": "stratum.ftc.theblocksfactory.com:3333",
"user": "login.worker",
"pass": "password",
"diffMultipliers": {
"stratum": 1,
"one": 65536,
"share": 65536
},
"algo": "neoScrypt",
"protocol": "stratum",
"diffMode": "neoScrypt",
"name": "FTC-TheBlocksFactory"
}
],
"algo": "qubit",
"driver": "OCL",
"implParams": {
"qubit": [
{
"impl": "fiveSteps",
"linearIntensity": 384
}
],
"fresh": [
{
"impl": "warm",
"linearIntensity": 256
}
],
"grsmyr": [
{
"impl": "monolithic",
"linearIntensity": 384
}
],
"neoScrypt": [
{
"impl": "smooth",
"linearIntensity": 64
}
]
}
}
Or, a more compact, yet complete form
{
"pools": [ ... ],
"algo": "qubit",
"driver": "OCL",
"reconnectDelay": 120,
"implParams": { ... }
}
Differently from legacy miners, settings in M8M are hierarchical in nature. It means that stuff goes inside other stuff rather than having a big blob. Let's took at the simple settings first.
driver: a string; this is not really used for the time being however it must be specified; for future compatibility, its value must be "OCL";reconnectDelay: a positive, non-zero integer; number of seconds to wait after pool disconnect before attempting a reconnect;algo: a string; default algorithm to mine when --algo is not used.
The pools array
Must contain a sequence of objects in the following form:
{
"url": <string>,
"user": <string>,
"pass": <string>,
"algo": <string>,
"diffMultipliers": {
"stratum": <number-greater-than-0>,
"share": <number-greater-than-0>,
"one": <number-greater-than-0>,
},
// optional below
"name": <string>,
"protocol": <string>,
"merkleMode": <string>,
"diffMode": <string>,
}
Let's start by considering the must have parameters.
url <string>: how to reach the server. This is the hostname with no protocol specifications (in particular no 'http' or 'stratum+'), usually followed by a port. See above for some examples. Specifying a protocol is technically incorrect and often overriden anyway. Some machinery has been deployed to allow that be a bit more resilient to input errors. Note (from the example above) you can leave the trailing '/' now, M8M will not bail out anymore because of it.user <string>: 'login' to server; many pools right now don't require any special login anymore but a valid wallet address to send coins. Sometimes additional server parameters are put there e.g. P2Pool allows you to do WALLET+number to specify explicit difficulty in case the default difficulty is too high for you.pass <string>: self explanatory; often unused but you need to specify one anyway!algo <string>: this allows M8M to activate only pools giving/expecting work using the algorithm specified by either config or --algo.diffMultipliers <object>: the object must contain at least three positive values stratum, share and one, they are all positive nonzero numbers, usually integers.
- Most of the time you'll only be concerned about stratum, it is a special value to interpret the "difficulty" numbers sent by pool server. In general, there's a standard setting but some pools operators think they know better and went for their own setting.
- one and share values are per-coin settings; you usually don't need to mess up with those however they must be specified in the config file as M8M by itself has no knowledge of them, only how to use them.
This is in contrast to legacy miners, which include this information in their own source code and select them usually according to algorithm specified.
Failing to specify one of the above values or specifying it in the wrong format will cause the whole pool setting to be considered invalid.
In contrast, optional parameters have a default value so when they are missing everything will just carry on but if you specify them, they must be in the correct format.
name <string>: default value is "[i]", where <i> is the index of the pool settings object in the pool array so, first object is [0], second is [1] and so on. It is used for presentation purposes when console output is used.protocol <string>: for future compatibility; must be "stratum" (which is also default). You usually don't need to mess with this.merkleMode <string>: default value is SHA256D, this is a per-coin property. Choose between "SHA256D" and "singleSHA256"; those are various ways to produce the header to hash.diffMode <string>: default value is btc, per-coin property. One of "btc" or "neoscrypt"; it affects the way network difficulty is extracted from the produced header to hash.
The implParams object
This is a bit more complicated. What it needs to do: after launch, the miner will hash according to a certain algorithm. This object tells the miner the settings to use for each algorithm. So, for each algorithm you want to use (either by config or by --algo) you need to have a corresponding value inside this object. The value corresponding to the algorithm being mined is extracted and it must be an array.
Each element of this array is then a configuration instructing the miner on how to use the devices.
As of 0.1896 beta this is quite stupid and there's no such point in using more than one configuration each algorithm nonetheless the format of each object is the following:
{
"impl": <string>,
...
}
As a start, M8M selects an algorithm implementation according to the value of the impl key. For valid values, refer to source code.
The web monitor also enumerates the possible values for each algorithm.
After an algorithm implementation has been selected, it is possible to consume additional configuration parameters.
In theory every algorithm implementation is free to define its own parameters; in practice the only parameter available (as of 0.1.896 beta) is linearIntensity which value is an positive not-zero integer.
You can find example values for linearIntensity at the releases page.
In practice those values will be "big" (128 and up) for mathematically-intensive algorithms and "small" (starting from 16) for "memory hard" algorithms.
So in practice, objects will look like
{
"impl": <string>,
"linearIntensity": <integer-greater-than-0>
}
In the future, there will be an additional entry in this object: require. Its goal will be to restrict the configuration to specific sets of devices.