Technical solution to eliminate desync in single-player sessions

"

There is more ontop of that

Really? Please educate me on my own proposal. What other server changes are needed?

"

qwave wrote:

"

There is more ontop of that

Really? Please educate me on my own proposal. What other server changes are needed?

Your hashing algorithm needs to be secure, GGG"s current one doesn't (GGG's current hashing isn't done for security reasons, its done to compare states)

Your proposal requires verifiably secure hashes, which are much harder to computer, especially when you start going 256/512

You can use an insecure hash if you want, but prepare to be hacked

"

Your hashing algorithm needs to be accurate, GGG"s current one doesn't (GGG's current hashing isn't done for security reasons, its done to compare states)

Seriously, you don't even know what you are posting. GGG doesn't even use a hash. What 'states' are they comparing?

"

Your proposal requires verifiably secure hashes, which are much harder to computer, especially when you start going 256/512

They are easy to computer. And again, how do you think PoE servers are generating random numbers? With fairy dust, right?


Believe me, if you are trying to target 'performance', you picked the wrong argument. My solution is significantly more performant than their current system.

"

qwave wrote:

They are easy to computer. And again, how do you think PoE servers are generating random numbers? With fairy dust, right?

The number that GGG need to compute are much less computationally intensive than what is needed for what you propose. How hard is this to understand?

He threw security out the window long ago when he decided to trust the client.

Tantabobo: The client is not trusted. The server must validate each and every state hash the same way that it currently does.

"

qwave wrote:

Tantabobo: The client is not trusted. The server must validate each and every state hash the same way that it currently does.

Yeah and guess what, with your proposal, because you are trusting the client, you have to use a secure hash to do this, unlike currently, where you can use something as unsecure as MD5

"

Yeah and guess what, with your proposal, because you are trusting the client, you have to use a secure hash to do this, unlike currently, where you can use something as unsecure as MD5

You literally have absolutely no idea what you are even posting.

"

qwave wrote:

"

In that case, the server would be able only to reproduce the potentially hacked simulation results transmitted by the client.

A hacked client state hash would contain values that were generated outside of the deterministic seed. This is the same way that servers validate encrypted passwords. Even though they don't have the actual plain text password, they can still validate the password matches. In this case, the deterministic seed acts as a 'password' to generate each random number.

In this case, there are no "encrypted passwords" for the server to decrypt and validate. The only things that are "deterministic" about the random number seeds are the emergent game simulation results they produce. The only way for the server to "validate" the client's results as legitimate is to reproduce its own simulation of the game session. That time-shifted, open-loop simulation would be subject to the same timing discrepancies that a real-time simulation would incur. Such a system would be incapable of producing reliable validation results.

"

qwave wrote:

Tantabobo: The client is not trusted. The server must validate each and every state hash the same way that it currently does.

If you don't trust the client and the server has to verify everything the same way that it currently does, how exactly does anything change?