Tim Olson

I’m discussing this on IRC in the Monero research channel if anyone is interested. I’ll close the ticket because ~~it doesn’t seem like anyone wants to discuss here.~~ I maintain...

A full JavaScript implementation is not necessary. See the "easy nonce" problem thread. Let's even suppose that a full processor _is_ necessary (I don't think it is, but for the...

https://github.com/tevador/RandomJS/issues/3#issuecomment-429041301 The fact that ARM cores are competitive should be a major concern. It is likely that an even smaller, simpler implementation will outperform, i.e. ASIC.

I must withdraw my recommendation for x86 and agree with @hyc. It is critical for mining fairness that we have many manufacturers. Using x86 basically grants the ASIC monopoly to...

Keep in mind that the ARM will have _one_ SHA-3 datapath per core. That datapath is tiny, so a dedicated SHA-3 ASIC might have thousands or tens of thousands of...

100% behind Blake2b as a fast hash in CPU's. I would like to add that the Athena project which evaluated the hardware performance of SHA finalists appears to be written...

Parser skipping would be fundamental for any good miner, software or hardware. Directly generating RISC-V has the benefit that a RISC-V CPU already embeds the "parser." Furthermore, generating RISC-V ties...

Even in the RISC-V generating case, an ASIC designer will embed the code generator itself, whereas a generic RISC-V CPU must still run the code generator as "non-native" object code...

If the goal is commoditization, RISC-V has a market of existing proven designs, but the generator problem remains. The market will start with RISC-V boards until ASICs embed the generator...

SRAM on chip will be organized into blocks likely not bigger than 256k each. For bigger rams, switching wires route across shards. Yes, propagation delay can be a problem if...