A new proof-of-work for Stellite
Stellite has always been about letting everyone participate in the network. That also means not only people with expensive and very specialized hardware should be able to mine. With the latest hardfork being V5 we still use a simple variant of CryptonightV8 (with half iterations) also known as CN-Fast. In V6 this will be changing and we’re bringing some groundbreaking changes to our PoW scheme and making it incredibly resistant to ASICs and FPGAs while also ensuring that it will stay relevant for a longer period. This will also be a huge boost for CPU miners and this is what is needed to make mobile mining relevant.
So what makes Cryptonight/XTLv6 special?
Cryptonight/XTLv6 makes use of the already ASIC/FPGA resistant Cryptonight-R algorithm and also a very volatile algorithm known as YescryptRH which was meant to make specialized hardware highly inefficient.
Some quick points about YescryptRH,
- Scalable from kilobytes (RAM) to terabytes (RAM + ROM) and beyond while providing adequate (or better) security vs. alternatives for same defender’s {time, memory} cost.
- Scalable to arbitrary SIMD vector width and instruction-level parallelism.
Optional bcrypt-like CPU friendliness (especially important at low memory usage settings). - Optional multiplication latency hardening (efficient at least on common x86 and ARM CPUs).
- Running time optimally tunable separately from memory usage and parallelism.
- Cryptographic security is based on that of SHA-256, HMAC, and PBKDF2.
Known unfortunate peculiarities of HMAC and PBKDF2 are fully avoided.
Yescrypt’s stance on FPGA and ASIC hardware.
With the YESCRYPT_PWXFORM flag set, Yescrypt performs a lot of random lookups typically from a CPU’s L1 cache, along with 32x32 to 64-bit multiplications. Both of these operations have enough latency that it is unlikely for it to be made much lower in specialized hardware such as FPGAs/ASICs that plague the current CN mining space. Yescrypt with YESCRYPT_RW flag set additionally discourages (TMTO) time-memory tradeoffs, thereby reducing FPGAs/ASICs flexibiltiy since it increases the area-time cost of attacks and the higher cost of this attack is achieved at a lower(defensive) running time. In conclusion with YESCRYPT_PWXFORM and YESCRYPT_RW flags we attain a lot more resistance against specialized hardware.
Why the addition of Cryptonight-R?
The reason we added the latest cryptonight variant is due to the following aspects.
ASICs will have to implement some simple and minimalistic instruction decoder and execution pipeline. While it’s not impossible, it’s much harder to create efficient out of order pipeline which can track all data dependencies and do more than 1 instruction per cycle. It will also have to use fixed clock cycle length, just like CPU, so for example XOR (single logic gate) won’t be much faster anymore.
ASIC with external memory will have the same performance as they did on CryptonightV2, but they will require much more chip area to implement multiple CPU-like execution pipelines. ASIC with on-chip memory will get 2.5–3.75 times slower due to increased math latency and randomness and they will also require more chip area.
So with the combination of both Cryptonight-R and Yescrypt we believe we have a very resistant Proof-of-work scheme in our hands.
What do you think the name of this new algorithm should be? Give us your suggestions on discord!
