search

jceminer / cn_cpu_miner

Cryptonote CPU Miner
35 stars 23 forks source link

Please add the new / Forked Algo Support - CN-AscendingNight #30

Open Cideg opened 5 years ago

Cideg commented 5 years ago

Tax-Project uses the CryptoNight (AscendingNight) hash algorithm, which is optimized for CPU-based mining and GPU resistance, with the Algo specializing in fair sharing of the hashrate.

Tax forked from CN-Heavy to to their own custom variant (Heavy+light)recently and was hoping you could add support? If you need anymore info please let me know.

Links Algo= https://github.com/Tax-Project/Tax/blob/master/src/crypto/slow-hash.c http://clashproject.org/tax/ https://github.com/Tax-Project https://github.com/Tax-Project/Miner-UI

Feel free to checkout this Test-Pool:

http://207.180.246.163/#

Wallet: http://clashproject.org/tax/

ClashLuke commented 5 years ago

Edit: AscendingNight is similar to CryptoNight (same scratchpad implode and explode) but it utilizes a different main algorithm. While CryptoNight uses one aes step every second step, AscendingNight uses one AES every fourth step, has some substitutional parts and things like that to perform less calculations for more memory intesety. In our private testing we came across performance boosts of 10% to 30% on Ryzen CPUs and up to 100% on older i7s. Since the memory utilisation is still the same, the algorithm is just as fast on GPU (mathematically speaking, not tested yet).

The thing cideg mentioned with Heavy, light and fast is just that, similar to CryptoNight, you can apply all the causal variations like CN-Heavy on AN as well (since it's just changing memory and iteration variables).

The point with the reference implementation of AscendingNight is that, while it's modular, it's still using 2MB as a scratchpad size and 2^14 iterations to increase the speeds of the validation process. By increasing the iteration number to the casual CryptoNight step count of 2^20 you'd see an even higher boost in the performance of CPUs compared to GPUs.

The important changes were done in the posr_aes macro. It can be found in here: https://github.com/Tax-Project/Tax/blob/master/src/crypto/slow-hash.c#L264

Similar to cideg, I'll tell you to let me know if you need any help or further information.

jceminer commented 5 years ago

Ok, i'll take a look. Looks simple, even to make in assembly, but... where is the 64x64=128 bits multiply? It was one of the instructions that gave advantage to CPU against GPU (since GPUs are pure 32-bits).

jceminer commented 5 years ago

Fine, that's simpler than i expected. Your algo is just about AES and XOR, easy. Will be probably in next version 0.33h

Cideg commented 5 years ago

"jceminer" Thank you very much for the fast support

ClashLuke commented 5 years ago

I removed all of it to have plain XOR and AES for now, the tail can be added later on again. Thanks for the quick response.

jceminer commented 5 years ago

There's a problem out there. I made the code, tested on the pool provided above: http://207.180.246.163/#

and got only rejects. So i compiled the reference miner from here: https://github.com/Tax-Project/xmr-stak-cpu

and it also makes only rejected shares. I need both a working pool and a working reference miner to do my tests.

Cideg commented 5 years ago

Can you try again, I had the pool idle

jceminer commented 5 years ago

Result rejected by the pool.

Same, only rejects from the reference miner. What miner works for you? I used this one https://github.com/Tax-Project/xmr-stak-cpu compiled with no change

Cideg commented 5 years ago

sorry, I think the miner is flawed, only it does not work for me anymore. I think the worm is in there right now

ClashLuke commented 5 years ago

Yeah, the reference miner is having issues right now. I am trying to fix them right now.

Cideg commented 5 years ago

Xmrig goes, I charge the same height, sorry for the circumstances http://207.180.246.163

jceminer commented 5 years ago

Ok warm me back when the xmrstak-cpu reference is fixed, i've no time to switch my test to another one. i chose it because it has the simplest code of all. meanwhile i release my 0.33h with no Ascending, but i reserve variation number 19 for you and keep my code warm, to release an AN capable version just after.

Cideg commented 5 years ago

Can you please provide us with a beta, that we can fix quickly? If it is not possible, but many thanks for the support. Once everything is overworked we will contact you.

thx mail: cideg@web.de

jceminer commented 5 years ago

my miner is not opensource, (despite being on Github, that I use à-la Claymore to have tickets and online doc only) so i cannot provide anything useful, but my miner provides the same result as the current xmrstak-cpu on the Tax reference page. https://github.com/Tax-Project/xmr-stak-cpu

So once you fixed that xmrstak-cpu code, i'll backport the fix to my own code and all will be fine.

ClashLuke commented

Yeah, the reference miner is having issues right now. I am trying to fix them right now.

Once he's done, i'll backport the fix

jceminer commented 5 years ago

i observed you updated a xmrigcpu on your repo, i take a look, if it mines good on your test pool so i backport the algo

jceminer commented 5 years ago

That's done and it works. I can mine on the test pool well. But the xmrig-asc code is just Monero-v1 with a lower amount of rounds (0x4000) and so is not related to the AES+XOR code I was talking about before. Which one is the real AscendingNight ?

Cideg commented 5 years ago

have to adjust step by step, somewhere is a mistake.

jceminer commented 5 years ago

Ok, so far the algo on your pool is more like CN-Masari than AN so i guess the reference miner xmrstak-cpu was good and your pool used the wrong algo. but that's just a guess. i'm waiting for the final answer to release my next version.

ClashLuke commented 5 years ago

I'll look into the code tomorrow. Once I've fixed it, you can adapt it.

ClashLuke commented 5 years ago

The reference XMR-Stak actually has a changed source, and it seems to be implemented properly. Well, atleast I cant spot a difference between that code and the one in the post_aes macro. Here is the link to it https://github.com/Tax-Project/xmr-stak-cpu/blob/master/crypto/cryptonight_aesni.h#L306

jceminer commented 5 years ago

same for me, this is the code i called AES+XOR but the test pool cited above rejects the shares it produces, but accepts the ones coming from the tweaked xmrig that is a CN-Masari with a loop counter of 0x4000, definitely not ascendingnight. i still need a working pool to validate my dev, i tried the official one but it looks down.

ClashLuke commented 5 years ago

I'll port it over to XMRig today so that the pool can point to correct code for validation. After that's done, I hope @Cideg can get the pool back up so that we can test a bit. I'm sorry that it got so delayed.

jceminer commented 5 years ago

Fine, just let me know when you have good miner (may it be a custom xmrig or stak) and good pool, based on the real AN fork, and no longer to that strange CN-Masari hybrid.

jceminer commented 5 years ago

Any news? I'm about to add for upx as variation 19, i can still add yours as 20, but i really need a test pool.

ClashLuke commented 5 years ago

We're working on the pool right now, but honestly, I think the next hardfork will come sooner than the pool will be there. Sorry for wasting your time.

jceminer commented 5 years ago

Ok, sad, it was a good CPU algo. I may still add the next fork directly, if it's still based on A-N.

SomethingGettingWrong commented 5 years ago

Sounds like an FPGA wet dream. FPGA's will eat an algo that relies on memory and no AES alive. think 50x cpu speed.then threaded 20 times on one fpga