Cryptonight algo tweak/ ASIC resistant algo about sumokoin HOT 16 CLOSED

A little tech background of the little data we have:

Baikal Giant N: 20 KH/s @ 60 W - $3600.
Bitmain X3: 220 KH/s @ 550 W - $12000 in may, then $7600 in june.

• Power envelope points to the Giant N using a single big chip - possibly a FPGA, however the X3 consumes more than what a single chip can dissipate in any normal cooling solution, hence it's using multiple chips. Since decently-sized (compute power by extension) FPGAs are expensive, and given Bitmain's past experience with ASICs and deep pockets, they're likely using an array of them.

• FPGAs can be upgraded to the extent of the free space left on them (LEs, memory), ASICs are hardcoded, they're like a FPGA hard-print.

• An ASIC with the same logic construct as a FPGA is generally faster. Think of it like turning left across an avenue to reach some place, everything is closer in the ASIC (you can U-turn), on the FPGA the path may be a little longer.

• Both may have external memory (some form of GDDR more likely because of bus width), it's unlikely they have HBM though.

Now, CN was thought to resist ASICs by being memory-intensive (the scratchpad, about 2 MB if i'm correct and 1 MB for lite).
For both cases (ASIC/FPGA) without using external memory increasing the scratchpad size will make it unfeasible to work-around without an ASIC respin (newer bigger more expensive chip) or bigger FPGA (or adding external memory, in any case meaning a new device model). This will take time, though a modest increase in scratchpad size may not hamper the ASICs at all if the thought about this possibility firsthand.
If they do use external memory then the size change won't hamper them in any way.
Increasing the scratchpad should also reduce CPU mining performance because of cache exhaustion (slower run times into main memory or less cores working on it).
For GPUs since they generally lack any meaningful cache they should break even on this (they have better bandwidth than CPUs because of wider bus size and faster GDDR memory).

Another solution as proposed before is using divisions.
ASICs are not inherently bad at them, it depends on what logic blocks were built into them.
Since crypto and hashing basically don't use divisions we can expect that it has no divisor unit(s) built into it.
FPGAs on the other hand may be upgraded to include it - as long as they have enough free space (in the form of LEs). You can get a rough idea of speed and resources at https://www.xilinx.com/support/documentation/ip_documentation/ru/div-gen.html
Also keep in mind that FP divisions are more expensive than INT ones (and harder to implement in ASICs and FPGAs).

from sumokoin.

@curie-kief That size isn't in xilinx's spec sheet, however let's take the most approximate one.
For a medium-sized device (big-sized would cost too much) at most 700 because of LE capacity, running at 90 MHz with a latency of roughly 8 cycles (effective 9 million divisions/second x 700). But that would sacrifice most of the available memory and all of the logic blocks, thus being only a divider chip.

from sumokoin.

Supposedly I've heard that integer division is slow on ASICs. Also, I've heard that operations on big numbers (arbitrary sized integers) is also slow. One idea could be to divide the final result by some large scalar. This would also slow down GPUs, but in the case of GPUs a miner could simply batch up several results and do the final step on the CPU.

It's likely my idea is either insane or requires a lot of tweaks, but here it is.

from sumokoin.

Thanks Phillip!
I ll leave this issue open for ideas, suggestions or comments.

from sumokoin.

@gustavoz

What would be your estimate as to how many dividers can be ran in parallel on a decent FPGA (signed division, 64 bit dividend / 32 bit divisor)?

from sumokoin.

One more question. If we assume that the devices are using only on-chip memory, what's ballpark number that they can have available?

from sumokoin.

Smallest starts at 1.5 MB and the top model gets up to 9.5 MB. Keep in mind that a top model price is 5 digits.

from sumokoin.

Is there a graph or something somewhere that shows the price/mb relationship?

from sumokoin.

I think Madame Curie :) was creating one last night.
@curie-kief
Edit: Oh price... My mind is stuck in hashrate cause that is what we were discussing

from sumokoin.

You can use a parts supplier, start at https://www.digikey.com/products/en/integrated-circuits-ics/embedded-fpgas-field-programmable-gate-array/696

from sumokoin.

Just do a multi-algorithm approach like x16r.

from sumokoin.

Might it not be a good idea to then create a full blown mini-VM like bf if we go that route?

from sumokoin.

Madame curie ( @curie-kief ) will be pushing within the next couple of days (hopefully within the weekend).

from sumokoin.

Consider some way to let Algorithm/Protocol to be changed automatically every month/season? Also, Need to let Wallet/Pool/Mining software supported. Could add into Roadmap by serval steps, then the ASICs will not able to follow up.
Or prevent ASIC manufacturer to get the full source code of new Algorithm/Protocol in time?

from sumokoin.

Hopefully the new algo being built will keep ASICs away for a couple of years (they always catch up eventually) so no need to fork periodically. Wallet, pool and mining software will of course be released before the fork.
The algo will be pushed on the official repo soon

from sumokoin.

Is the difficulty algorithm going to be upgraded in the fork? I have another issue that is open here and that recommends my algorithm that a lot of Monero clones are going to.

from sumokoin.