[Feature request] Support variant option from xmrig-proxy

[plavirudar]

XMRig proxy allows custom configuration of the variant from within the proxy, so that the miner knows what variant to use even if the major version field of the block template is wrong. https://github.com/xmrig/xmrig-proxy/issues/145

Please support this variant option so that it is possible to run xmr-stak without needing to change the config every time.

[psychocrypt]

What is variant for you? Do you mean the block version.

[xmrig]

I extend job object with field variant, possible values:

• -1 or missing field, miner detects PoW from block version.
• 0 forcebly use original/old algorithm.
• 1 forcebly use new Monero/AEON v7.

GRAFT coin currently use v7 block version, but original algorithm, so simple autodetect based on block version will fail in this case. This field sent in each job, proxy now support changing pools without restart, so miner should switch PoW on fly. Thank you.

[psychocrypt]

If graft uses still the original cryptonight than the blockversion is independent. The new monero pow is no longer cryptonight therefore it should not metter that GRAFT is still using cryptonight. Do you try to support with your proxy that you can mine against different currencies? (nicehash 3.0 open source)?

[xmrig]

Just trying to minimize hurt of new PoW. I not related to GRAFT in any way, when I added this field, I did not know about the issue with this coin, this field was added for solve possible issues in future, but the future has already come. Until old and new PoW is almost same, is not big deal to change it on fly.

[psychocrypt]

I try to understand why someone must jump between the algorithms. At the end the block version can only increase and never decrease. This mean if I select cryptonight_monero (that how we call it) than we know that as soon as blockversion is 7 we need to change to the new pow but than never back. All other coins with cryptonight will be version agnostic. If we see in the future more and more pow changes it not helps to have something than a variant only. We should name each cryptoalgorithm unique and than handle the forks clean depending of ther block version. Ignoring the blockversion and following some commands of an pool sounds not right. Miner are no slaves of an pool, with such a feature we lose the possibility than that miner controls what he will mine. I am not sure if this openes an attack vector against miner.

I am not against this feature but think that the miner should keep the control about the algorithm.

@fireice maybe this discussion is also interesting for you.

[psychocrypt]

cc-ing @fireice_uk

[fireice-uk]

@plavirudar No, we decided to move to coins rather than algorithms. So if you put in monero2, Monero will work. If you put in karbo then Karbo will work etc.

[xmrig]

@psychocrypt Common scenario, people switch coins based on profitability or other reasons, miner was never know what exactly mined, but after fork people will lose ability to switch between Monero and other coins without change miner configs. You are right in future may need something better than just single variant field, may not.

@fireice-uk Use coins is utopia, how many coins now? 20 or so, good luck to make it up to date.

[plavirudar]

@psychocrypt

We should name each cryptoalgorithm unique

I always thought that the algorithm naming convention was more elegant, since that was the thing that mattered, not the specific coin. You're mining Cryptonight original or Cryptonight Variant 1, not Monero, or Karbo, or something else.

In any case, the miner should always mine the algorithm that it is being told to by the pool, since they will just be wasting time submitting invalid hashes otherwise.

Imagine that you are mining a coin (such as Graft) that has a nonstandard mapping for block version and variant (v7->CN0, v8->CN1). In the current system, you will need to manually edit the configs on all of your miners in order to change to that coin. The whole point of using stratum proxies is to minimise the friction required in changing configs across a large number of mining rigs.

If nothing else, consider the effect on your own operations. Someone who's mining to different cointypes will not be able to donate directly to your pool if you don't implement this system.

[xmrig]

Looks like I see the future again, I not just added variant field, I also added coin field, possible values XMR, AEON, any 3-4 letters code and SUMO as well. It's already implemented and released, but not used on miner side yet.

[psychocrypt]

@xmrig but than the variant is useless. The miner can switch based on the currency. The limitation with the 4 letters is limiting and assume that all future currencies has not more letters. This is like limiting variable name lengths (fortran bashing). The question than is how we can avoid that the pool switch between different currencies with different scrtachpad size. Never the less each miner should support coin switching only by opt in. If I mine only to support one currency like monero I will not spend my hashrate to other coins to make this coins more stable.

[psychocrypt]

@xmrig How is the user credited if the pool is switching the currency? The miner address is only valid for one currency.

[plavirudar]

@psychocrypt The intended use case is for someone running the xmrig-proxy stratum proxy to be able to switch between multiple coins easily, without needing to change the configs on all of the xmr-stak miners which are being pointed to the said proxy. The proxy is address-agnostic, and reports the appropriate address to the appropriate pool from the proxy's config file.

Example:

I have 20 rigs, each reporting to the xmrig-proxy instance using "rig-NN" as their payment address.

xmrig-proxy takes the submitted shares from the rigs and submits them to the pool, replacing "rig-NN" with the appropriate payout address for the pool, eg 4xxxxxxxxxxx for Monero or Gxxxxxxxxxxxx for Graft.

In this case, if I wish to switch from Monero to Graft, I will need to edit the configs of all 20 rigs. Implementing this feature will make it easier to perform the switch, since you only need to edit one line in the config of the proxy.

[plavirudar]

@psychocrypt Any updates on whether support is being planned for this?

[psychocrypt]

Not for the next release. Is there somewhere a documentation about the new fields and about the meaning.

[plavirudar]

@psychocrypt It's already documented above: https://github.com/fireice-uk/xmr-stak/issues/1192#issuecomment-375954323

-1: Current behaviour 0: Force original Cryptonight hash 1: Force Cryptonight v1 hash

[fireice-uk]

@plavirudar the only thing you can't do right now is force monerov7 hash without a minor modification in the code. We chose to support the pow change in a slightly different way.

If you want to mine graft, just put graft in the settings.

[plavirudar]

@fireice-uk I understand that this is likely not high priority at this point, but I would like to switch between coins from a stratum proxy (such as xmrig proxy) without having to change configs on all of the miners just to account for the block versions of different coins.

Please consider implementing this feature request. Thank you.