Dreadlockyx

Hi, When I try to browse to http://hwbot.org/competition/rookie_rumble_amd_46/ I get redirected to http://localhost:7774/#!/round/rookie_rumble_amd_46. Moreover, I see that http:// does not get redirected to https:// while at the same time on HTTPs pages some mixed content is present. This should be fixed, as one can easyily send a password in the clear without knowing it. Thanks, Dreadlockyx.

This shit is fucking lit as fuck ! Next OC championships gotta be in Reykjavik.

This is the pinnacle of cancer

A true masterpiece

I sense snake oil.

Holy shit 8 bucks for 4 screws

Any reason for the being so ?

Happy new year fellas !

Perfect when you want to work relaxed or just chill

There could be an offline version, but since the program is open source anyone could fake the score.

Hi there In an effort to make benchmarking cheating and tamper-proof, I have come up with a simple idea. By using existing technology and a few cryptography principles, it is possible to make score falsification hard. One of the key elements here is NTP. It is a network protocol that allows a client device to sync its internal clock with that of a server, with decent precision (normally <1s). The second element is the KDF, or key derivation function. Put simply, it is used to derive a secret key from a user-provided password which will be used for encryption/decryption when using a symmetric key cipher (such as AES). Secret keys are normally 128 or 256 bits long, meaning there are up to 2^128 or 2^256 keys, thus hard to predict. scrypt is a memory-hard KDF, meaning that in contrast with normal KDFs, it requires a given amount of memory (which can be a lot depending on some parameters). Also, the higher the memory cost, the longer the derivation time. Here is the notation for the next part: R - random value S - salt (also random value but not secret) K <- secret key RNG - random number generator, param: output size in bytes KDF - key derivation function, params: password, salt T <- Unix epoch NTP <- network time protocol, param: server to sync with The benchmark would work as follows: 1) Server: R <- RNG(32) 2) Server: S <- RNG(32) 3) Server: K <- KDF(R, S) 4) Client: T <- NTP(server) 5) Server -> R+S -> Client 6) Client: K <- KDF(R, S) 7) Client -> K -> Server 8) Server: check if K matches That's the basic principle of the benchmark. Now it certainly needs some tweaks here and there but overall it should work as is. One of the things that can be implemented to prevent the client to predict the computation time is to send random computation parameters and to measure the client's internal clock right after the computation is done. If the difference is >100ms, the score is considered null. What do you guys think ?

Good job mate !

I'll be getting a pair of KRK Rokit soon. These bad boys are awesome. As for the headphones, M50x.

^10/10

I'd say you just invent some bs. They're not going to come to your place and check it, are they ?

I think we have to try. We may speculate as much as we want but without actually testing stuff it's impossible to know if the general public will like it or not. I, too, would love to see overclocking become more popular amongst mortals but it seems like a long (and painful ?) process.

You forgot techno

The problem is that there is no suspense except for a bunch of nerds interested in computers. You can sit back on your couch and casually watch football or gaming competitions, but overlocking ? Nah, forget about it.

Second video sounds so 80's

Holy bunnyextraction the second track is dope

If you really want to have all the stats, you must take all the events into account. For example, a CSGO championship might not only be about the main event but also all the qualifiers before that.

The title says it all Merry Christmas to you all, people ! May Santa bring WR's to your family