Adding minotaur algo (Ring RNG)

[kr1z1s]

Please add new algo for CPU - minotaur, Ring (RNG) coin

http://ringcoin.tech/ https://github.com/litecoincash-project/ring

Algo - https://github.com/litecoincash-project/node-multi-hashing/blob/master/minotaur.c https://github.com/litecoincash-project/node-multi-hashing/blob/master/minotaur.h

[JayDDee]

Technically this looks doable but has little potential for improvement.

The algo is structured similar to ZR5 and has the same optimization issues. Each thread takes a different path which prevents any kind of parallel SIMD optimizing. Some of the hash function can use AES (groestl, shavite, echo) and a few can do linear AVX2 (luffa, cube, simd) but that only represents 6 of the 16 functions. A rough guess would be 10% to 20% improvement is possible.

The referenced code is written in C for node.js and appears to be contained to 2 files, minotaur.h & minotaur.c with no apparent changes required anywhere else. This suggests an fairly straightforward integration with cpuminer-opt.

Before I commit to it I want to ensure the algo has staying power. There are already too many algos that are now obsolete and just clutter in the code. In hindsight they were a waste of time.

If it gets picked up by any of the bigger multipools it would help.

[JayDDee]

Some technical notes:

The stratum protocol is assumed to be standard with no tweaks.

A scanhash function needs to be defined for minotaur to manage the nonces.

The garden is constant and only needs to be initialized once at startup.

[kr1z1s]

These guys added minotaur support to their miner - https://github.com/rplant8/cpuminer-opt-rplant/releases/tag/4.0.31

And optimized it https://github.com/rplant8/cpuminer-opt-rplant/releases/tag/4.5.4

But their miner only works on their pool. On my pool after 2-3 accepts only rejects

[JayDDee]

Not likely. There are easier ways to restrict the miner to their pool, and they don't do that anyway. If it works in rplant pool I suspect a problem with yours pool.

[kr1z1s]

Not likely. There are easier ways to restrict the miner to their pool, and they don't do that anyway. If it works in rplant pool I suspect a problem with yours pool.

No. This miner - https://github.com/doktor83/SRBMiner-Multi/releases - work normally. The correct block was already found.

[JayDDee]

Maybe a bug in the miner then, I don't think it's intentional on their part.

How is the performance between the unoptimized and optimixed rplant, and srbminer?

[rplant8]

no tweaks in my pool, multihashing made from original cpuminer-multi. my miner is optimized this is how you write in the first comment. everything works on multiple pools. I think kr1z1s has problems with stratum/multihashing

[JayDDee]

@rplant8, thanks. I agree the problem is likely with the pool.

[kr1z1s]

@rplant8, thanks. I agree the problem is likely with the pool.

That is, if this miner (version 4.5.4) works well on one algorithm (yespowerr16), but poorly on other(minotaur), then the problem is in pool? Fine fine )

Stratum implementation the same thing on all my pools. And another fact. Old version of their miner works perfectly - https://github.com/rplant8/cpuminer-opt-rplant/releases/tag/4.0.31

After optimisation (version 4.5.4) miner not work.

But there is a problem with my pool. Fine fine )

[JayDDee]

This is going off topic, I suggest another issue to duscuss the rejects further.

I can think of 2 problems that could cause intermittant rejects:

1. Diff target mismatch between the pool and miner. That would result in submitting intermittant low difficulty shares if the miner is working with a lower target than the pool..

2. Hash function order mismatch, The hash order is always changing, some may be incorrect and produce invalid shares.

I suggest testing at an independent pool. rplant8 claims it works at multiple pools. kr1z1s chould test at the pools tested by rplant8 and rplant8 could test at kr1z1s pool. That should resolve where the problem lies.

I can follow the new issue and provide any input that might be helpful.

[kr1z1s]

This is going off topic, I suggest another issue to duscuss the rejects further.

I can think of 2 problems that could cause intermittant rejects:

1. Diff target mismatch between the pool and miner. That would result in submitting intermittant low difficulty shares if the miner is working with a lower target than the pool..
2. Hash function order mismatch, The hash order is always changing, some may be incorrect and produce invalid shares.

I suggest testing at an independent pool. rplant8 claims it works at multiple pools. kr1z1s chould test at the pools tested by rplant8 and rplant8 could test at kr1z1s pool. That should resolve where the problem lies.

I can follow the new issue and provide any input that might be helpful.

Excuse please. We are waiting for your implementation.

[JayDDee]

Excuse please. We are waiting for your implementation.

I need both a reliable pool and a reliable miner as a control to properly test my implementation. One or the other is not and it needs to be fixed, or at a minimum, identify which is at fault.

I'm still leaning toward a pool problem. I will not proceed until I can be confident about testing.

I will also need pool login credentials as I don't intend to install a full node.

[kr1z1s]

Excuse please. We are waiting for your implementation.

I need both a reliable pool and a reliable miner as a control to properly test my implementation. One or the other is not and it needs to be fixed, or at a minimum, identify which is at fault.

I'm still leaning toward a pool problem. I will not proceed until I can be confident about testing.

I will also need pool login credentials as I don't intend to install a full node.

http://p2p-south.xyz:18116/static/ My pool. Based on https://github.com/jtoomim/p2pool (I'm p2pool developer and contributor) Stratum - p2p-south.xyz:18116 User - RingWallet. (worker name supports RingWallet.worker1 or RinfWallet_worker1) Password - any

[JayDDee]

I have a working prototype for cpuminer-opt at p2p-south.

The implementtaion was trivial, I just needed minotaur.c from node_multihashing. I added a generic scanhash and gate registration function, swapped the args in minotaur hash, substituded openssl sha512 for sph and subsituted optimized versions of echo, groestl, simd, luffa and cube. And it worked on the first test. It's the first time that has happened with a new algo and completely unexpected. That was fortunate because I had no way to debug rejects without a reliable control.

The only problem was the starting difficulty is way too low. I was submitting over 100 shares/min with only 1 thread.

I want to make a few more code changes before I release it.

The rejects using rplant miner is not my issue but the excessively high share rate may be a contributor. I request no further discussion of that issue here.

[JayDDee]

Stale share are being reported as rejects because the pool doesn't give a reject reason. There's nothing I can do about it.

[2020-05-10 18:52:11] 137 Submitted Diff 0.0010528, Block 189392, Job 224884352580750775094565350822522309762 [2020-05-10 18:52:11] 138 Submitted Diff 0.0039147, Block 189392, Job 224884352580750775094565350822522309762 [2020-05-10 18:52:11] New Job 320001961374064136623685592432787148261 [2020-05-10 18:52:11] 137 Accepted 133 S0 R4 B0, 4.704 sec (179ms) Diff 0.0010528 (0.000277), Block 189392, Job 224884352580750775094565350822 [2020-05-10 18:52:11] 138 A133 S0 Rejected 5 B0, 0.061 sec (282ms) Diff 0.0039147 (0.00103), Block 189392, Job 224884352580750775094565350822 Hash: 000000ff7274a41323600000... Target: 00000e9e8bf99b1e0d000000...

[JayDDee]

Minotaur added to cpuminer-opt-3.13.1.

[kr1z1s]

I have a working prototype for cpuminer-opt at p2p-south.

The implementtaion was trivial, I just needed minotaur.c from node_multihashing. I added a generic scanhash and gate registration function, swapped the args in minotaur hash, substituded openssl sha512 for sph and subsituted optimized versions of echo, groestl, simd, luffa and cube. And it worked on the first test. It's the first time that has happened with a new algo and completely unexpected. That was fortunate because I had no way to debug rejects without a reliable control.

The only problem was the starting difficulty is way too low. I was submitting over 100 shares/min with only 1 thread.

I want to make a few more code changes before I release it.

The rejects using rplant miner is not my issue but the excessively high share rate may be a contributor. I request no further discussion of that issue here.

Thanks. Sorry again for off topic

[JayDDee]

No problems reported, so closing.