The problem with this is that the game needs to be fully deterministic and you'd be surprised how many games use random numbers to help determine outcomes like damage etc.
This can also cause problems when you have complex physics models, many physics engines are not deterministic and small changes between the ways that different CPUs deal with floating point numbers can cause the game to generate a completely different hash.
Your comment about the differences in how CPUs deal with floats is very interesting.
I found the following interesting comment, from a GPG employee, talking about how they take care to ensure their float math is deterministic:
"I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor."
For anyone else reading, I'd also suggest reading some of the followup posts such as this one: http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&...
This is news? Isn't this the entire point of the IEEE754 standard, to save us from the days when programs that were well-conditioned on a VAX would become numerically unstable on a Cray?
'Cray instability' sounds like a Star Trek episode but it is apparently something that could happen.
The physics engine is a bit more difficult hurdle I suppose.
Why not just take the user input from the client, and send it both to the model of the world on the server, and also to a non-authoritative model of the world on the client? The client is then immediately responsive, as the client model of the world is what is rendered, but if the model of the world on the client diverges from the model of the world on the server, the server overrules it.
This would ensure the client did not violate position rules, while still keeping it responsive, at the cost of an occasional noticable update when models get too far out of synch.
As far as I know many games have done this, since Quakeworld. I might be wrong, my knowledge is a little rusty?
Other issues remain that this doesn't solve (e.g. aimbot).
EDIT - Here's a wiki article this: http://en.wikipedia.org/wiki/Client-side_prediction which links to this article describing client side prediction in Half Life (so you can presume there is something at least as sophisticated in Source): http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...