So this doesn't get lost:
michael-herwig | 3 points | 1 hour ago
For everyone looking into this thread, asking themselves if there is anything reasonable on these claims I will shortly state my understanding.
1: Nerva was GPU mineable in Adaptive v1 until v3. Over time it grew more and more GPU mineable, suggesting that it was designed that way to look like actual growth, possibly.
The claim is that the number of iterations will not change drastically on given heights because of the modulus operation. Thus the number of iterations will always be 0x40000+[1..63]. The author claims that a much faster, or even GPU, implementation could be made for each different value which would yield a drastically performance boost.
This is incorrect. The suggested solution of loop unrolling is not applicable. Compilers have a built-in limit of how many loops can be unrolled at max. For GCC8.2 this is 16. I have coded a simple example here, simply increase the iterations by 1 and you will see the assembler implementation switches to jumps.
Regarding the GPU claim, incorrect. The number of iterations is not the hard breaking edge for GPUs. It is the memory consumption/random access and memory critical path. For example, the initial version of CryptoNight has a fixed iteration for all hash computations and that does not make it faster or slower in any way. Please have a look into their specification if you want to read more about the idea.
General Suggestion: If you claim to know performance improvements you better benchmark first. Many C++ programmers tend to think they know how to write the faster code and in the end, it does not matter. There is a great talk about it on youtube you may want to check that out.
2: The typo is returning a value by reference to a function... If we return the wrong type, we get an error. If we do not return an incorrect type, we don't get an error, and the program thinks we have the correct value (when it could have changed between calls)
What do you mean by hacks? Returning by const reference is a performance optimization and it is known to easily introduce errors, that is correct. But what do you want to achieve by 'hacking' it? You will have an invalid version of the hash try to submit it and other daemons will not accept it. The project is open source and everyone can look into these changes. Thus if you want to 'hack' someone you would have to force them to update their versions with your injected one and that's where a real hack starts, in my opinion. You may want to distinguish compilation and runtime more, next time.
3: Nerva claims to "DDoS pool operators" with 4kB of random data, sent with each block. This data is derived using Mersenne Twister. Except that the block size (on their explorer currently) is only 85 bytes.
Incorrect, again. First Nerva queries multiple blocks, second, it is a very common technique to expand more pseudo-random data out of small memory chunks (like kinda every password hashing algorithm does). The Mersenne Twister is a random number generator to help for this regard.
In General
These claims are misleading at least and it looks like you threw them out of nowhere without any researched evidence. In my opinion, it is always fine to do so and ask for feedback if you think something could be wrong but I would encourage you to step a bit back and be more careful with your claims because you may be wrong, like in this case. As a result, stating these claims may hurt your reputation and the reputation of the blockchain you are working on. Finally please read you're COC.
Show Posts
