[drum55]

It doesn't matter if your hottest loop is using string comparisons, as another poster pointed out in C you aren't even doing the majority of the second hash because you know the result (or enough of it) before finishing it. The JavaScript version just does whole hashes and turns them into a Uint8Array, then iterates through it.

[bawolff]

I dont understand what you mean. Are you saying that in C you only calculate the first few digits of the hash? That's not how sha256 works.

Edit: oh i think you mean in c the string comparison short curcuits. I would expect the same to be true in javascript too. Its true in most languages.

Maybe you are just worried about general language overhead, which is a fair point. Is the anubis check even using multiple threads? For the c case, the real benefit wouldn't be if you can use C, but if you can use the GPU.

The whole thing is kind of silly though. SHA256 is a terrible choice of hash for PoW. They should be using argon2 or something memory heavy.

[drum55]

The language matters, but your original guess was actually correct, you can do tricks with sha256 where you only end up calculating a fraction of the total double hash in order to get a pass or fail.

Modern bitcoin miners do a double sha256 hash and increment in just a little bit more than a single hash of work. The input is 80 bytes, which is two compression rounds of 64 bytes in sha256, only the data in the second round has changed (the appended nonce), so you don’t bother doing the first compression round again. With other quirks you can end up doing multiple hashes at once “asicboost” due to partial collisions within the input too.

[bawolff]

Oh good point. It looks like anubis is using 64 byte random plus a nonce. Unless i'm missing something it seems like using 56 bytes random plus 8 byte nonce would be a better design or maybe hmac'ing the nonce & data together.

But then again using sha256 doesn't make sense at all.