Lyra2rev2 is already ASIC'ed.
Tribus, Keccak, 0xbtc algos are dead if speaking in terms of profit
The last coin which is used Phi1612 algo is a small shitcoim called Folm with about $100/day trading volume on exchange, and even this small coin is going to fork with algo change
On Phi2 even old RX Polaris are provide almost two times cheaper hash cost. $44/Mh vs ~$25/Mh. nvidia Pascal - even bigger difference
Zcoin - the biggest Lyra2z coin is going to fork at Dec 10th, hashing algorithm is also will be changed. Also 35Mh it's very overestimated hash rate for this type fpga chip... real achievable ceiling is about 25mh/s
On cryptonight v8 fpgas can't achieve any reasonable hashrate due to sqrt and div which was added into V8 cryptonight codebase. in terms of hash cost fpgas can't beat AMD Polaris and nvidia Pascal GPUs.
No doubt that payback period of these fpgas will be much higher than 1.5 year. (very optimistically) and we are not taking in count huge amount of bcu1525 and chinese copycats which are hitting network these days
Owners of all this great mining equipment will be screwed with unreasonable roi period.
I want to repeat: nowadays mainly only miming hardware manufacturers and hardware resellers earn money in crypto mining sphere.
This is a game where miners will always lose
In near time we'll see more and more coins forks with asic, fpga resistant algos.
Hi.
We do accomplish 25MH/s in simulation on Kintex based devices already. The VU3P has more FPGA logic so we expect that it should see improved hash rate, but we have not done simulation testing with VU3P yet, as our expectation was that people would be more interested in the cheaper UM miner (this might be a wrong assumption on our part).
I do not understand where your cealing of 25MH/s for Lyra2Z would come from? The basic hash done in Lyra2Z is just a chained 64bit blake2b (8*8*9 times chained for Lyra2Z) and that is trivial to get really fast. Your limits will comes in how you design the memory routing for the 768 x 8 x 8 bits work matrixes needed.
Now our simulation assume that we have no issues with power delivery or cooling. And we are not assuming that the FPGAs will be in some power-saving low voltage mode, we are giving them all they can handle, and our PCB layout design will support this reliably. But that is also why we do not want to go bigger then VU3P, as a massive combined package like VU9P has much more issues with power delivery and heat dissipation.
While we have not done enough work to say much about any Cryptonight version yet. I do not agree that integer division and square root operations would be a FPGA blocker. Just a simple Radix2 divider would not be to big and can be heavily pipelined, and then there are the hardened DSP blocks "Configurable ASIC blocks if you will" in most FPGA's that can be used for thees purposes as well.