xmrig / xmrig-amd

Monero AMD (OpenCL) miner
GNU General Public License v3.0
415 stars 227 forks source link

[Request] Support for KangarooTwelve (Aeon v8) #250

Closed stoffu closed 5 years ago

stoffu commented 5 years ago

(Cross-posted at https://github.com/xmrig/xmrig-nvidia/issues/261)

Aeon is planning to change its PoW to KangarooTwelve (https://github.com/aeonix/aeon/pull/108) in the next v8 hard fork. I've already made a patch for the CPU version (https://github.com/xmrig/xmrig/pull/1004) by simply copying the reference code, but my expertise in GPU coding is quite limited, so it'd be very much appreciated if you could provide a good GPU implementation. You're welcome to create a funding proposal at https://www.aeonfunding.com/proposals if you want.

A testnet pool: http://162.210.173.150:8080

SChernykh commented 5 years ago

First of all, this is not Cryptonight-family algorithm, it makes more sense to do a separate miner. Second, this algorithm will be overrun by FPGAs from day 1, GPU/CPU mining will be useless.

stoffu commented 5 years ago
  1. It makes sense since XMRig is generally dedicated to supporting CryptoNote coins. By your logic, RandomX shouldn't be implemented in XMRig since it's not CryptoNight family.

  2. The point is that there must be at least CPU and GPU miners ready at the time of forking in order for the switch to be acceptable to the community. It seems to be a tall order to require FPGA (or even ASIC) miners be ready at the fork, so there'll be an arms race after the fork.

xmrig commented 5 years ago

Different setting for CN algorithm it major issue, I working on it, so if thing like RandomX will come, I will be ready, I naturally have no choice support it or not.

K12 is different thing it ASIC/FPGA friendly algorithm, so sooner (day 1) or later CPU/GPU become obsolete/useless and miner too, it war already done. I discussed it with @SChernykh and we will not support this algorithm. Sorry.

stoffu commented 5 years ago

OK, too bad that you choose not to support k12 even if GPU mining might remain profitable for some time after the fork.

SChernykh commented 5 years ago

The problem is GPU miner will require some considerable work and time invested from us, and this work will be thrown away probably after a few days (FPGA designers are working on it already).

stoffu commented 5 years ago

FPGA designers are working on it already

Oh, could you share some information?

SChernykh commented 5 years ago

@stoffu I'm in FPGA discord (including closed dev part of it). They had keccak implemented for a long time since it's used in other PoW algorithms. Creating pure keccak miner is a matter of a week or two. Regarding KangarooTwelve, this is what GPUHoarder said:

Imagine every available FPGA will take this one for a while

I guess he meant that before ASICs come, all VCU/BCU cards, BlackMiner F1's and even Acorns will mine this.

stoffu commented 5 years ago

The problem is GPU miner will require some considerable work and time invested from us

I thought implementing K12 for GPUs would be trivial since it's identical to the basic Keccak with the number of rounds reduced to 12 for the case of mining where the mining blob is much smaller than K12's chunk size (8192 bytes).

It doesn't have to be extremely optimized since FPGAs will beat GPUs soon (or immediately) anyway. The intent would be to make the fork look less abrupt to the existing CPU/GPU miner community (otherwise they might get upset crying "we don't even have the miner code ready!").

But perhaps you're right, it may not make sense to try to support CPU/GPU mining at all from the beginning.

SChernykh commented 5 years ago

I still think you need to talk to FPGA devs directly, they'll be happy create a miner for K12 before the fork: https://discord.gg/ZNfB8M

stoffu commented 5 years ago

@SChernykh Thank you so much for your input! I'll definitely contact them.