tevador
Tweaking parameters to allow for limited WASM mining
I'd like to migrate Membercoin to RandomX POW and hope for advice on tweaking its parameters for our use case.
Wanting to maintain ASIC resistance (and GPU resistance as a bonus) but also allow web-browser WASM pool mining for small amounts of coin in a convenient, but inefficient way. This is so that casual users can mine a few satoshis to use as gas to set up a username, and make a few posts on the social network attached to Membercoin.
From what I can gather, floating point is the big impediment to WASM mining, so I'm guessing I'll need to change the frequency of floating point instructions, and replace them with integer instructions. This looks straightforward enough to do, but what other ramifications would this have aside from reducing ASIC resistance?
I'm wondering if the mining in light-client verification mode would then be sufficiently efficient.
I see a figure that fast mining is 20 times more efficient than light client mode. Adding on the additional slowdown of WASM, I might expect light-client WASM to be 40 times less efficient than fast native mining (assuming floating point instructions removed). I'd like to get that ratio down to about 8 and hope there is a way to do it with the least compromise to ASIC resistance. What would be the best parameters to tweak for this?
WASM doesn't support floating point rounding modes, so you can try to disable CFROUND only and go with default rounding mode. As far as I can see, WASM has instructions for +, -, *, / and sqrt, so it should be possible to implement. But you'll have to run it in light mode with interpreter (not with JIT), it will be very slow anyway.
P.S. Regarding ASIC resistance, removing CFROUND does reduce it a bit, but in your case any regular CPU running in fast mode with JIT can already be seen as an "ASIC" compared to browser mining.
I did some WASM performance evaluation a couple years back. You can actually do JIT compilation with WASM, so you are not limited to the interpreted mode. You can also run the full mode in theory since WASM supports up to 4 GB of memory, but in practice it depends on the limits imposed by individual browsers. In any case, mining in the light mode is not worth it.
What makes WASM infeasible is the CFROUND instruction because only round-to-nearest mode is supported. Once you remove it, WASM miners should be possible.
Another performance bottleneck is caused by the multiply-high instructions (IMULH_R, IMULH_M, ISMULH_R, ISMULH_M) since WASM currently has no support for these and they have to be emulated with 4 regular multiplications and some additions/shifts.
So if you disable the aforementioned 5 instructions (and optionally reduce the dataset size), it should be possible to implement a fairly efficient WASM miner.
Those are really helpful suggestions, thank you @tevador and @SChernykh !
From my research, I think I can only rely on a maximum of 512MB of memory from the browser - it might only allow for a 256MB mining. Is it possible to change a parameter to change fast mode mining to 256MB and would this be foolish/reckless?
I saw that there was a WASM implementation on minero.cc , but was slowed down by the FP - I'll see if I can track down that implementation rather than re-implementing it.
Some (2y old) figures on memory WASM can expect to secure - https://forum.unity.com/threads/android-chromium-unable-to-grow-allocated-memory-above-256mb-confirmed.1014475/