Ok I think the best approach currently is to rewind on the server to the time of press and inside the package the client sends to the server containing the timestamp to rewind to, I simply crypt this area of the message or something like that. I can't find any other solution other then rewinding on the Server.

Synergi, you're overthinking it. Every prediction system is, by definition, going to be a little bit wrong sometimes. There is no solution to that. All you can do is mitigate the problem, which usually means correcting the client a small amount if and when the server reports that its movements were somehow wrong.

Networking and game design are closely related and there are always trade offs involved. If you're making a competitive game and the single press of a button determines the outcome (e.g. your race example), then you might want to forgo responsiveness and let the server decide when the button was pressed. If that makes your game feel too unresponsive, you can try hiding the latency with client side prediction/animation/sounds. But you could also go for another design, where the outcome is not determined by a single button press. If you need to maneuver through some track and other players can interact with you, it becomes less attractive to send some input in the past, because it requires the cheating client to not have given any input until that point in time (doing so would prevent the server from accepting the past input since all packets are sequenced) and it binds them to that choice which might make reacting to other events impossible.

For a game like Smite, I can image that movement allows for some rewinding to make that feel as responsive as possible, but the use of abilities may not.

Another point to note is that even without a rewinding feature, a hacker has an advantage as they can estimate the ping and send the "start running" command to arrive the instant the race is due to start.

Ideally you want this to be in the game by default, the client's simulation should run a little bit ahead of the server. The added benefit is that your server will have to do less rewinding and forward simulations, which can be costly (processing wise) depending on the type of game.

Server rewinding to account for player's ping spike is a terrible idea imo. If a player has unstable network condition, he/she should not expect a smooth gameplay.

Don't have to be spikes at all, simulations will diverge even with best connections out there. Unless you have lock-step, you either need to have rewinding or continuously correct clients. For some games (e.g. FPS), it's imperative to have rewinding for them to be 'playable'.

I wouldn't say you need server rewinding. If the client somehow becomes divergent from the server then usually I'd just drag the client back into place.