Does it need to do something? It's perfectly acceptable if it shows "kaboom" when the next tick's server reply comes in (OP says 20 updates per second, so that's not long), is it not? Player will still be standing on the trap then.
The Bloom filter idea sounds great, but I'm unsure of how you'd implement it in practice. If you're treating it as a bunch of false positive collisions, what's the client supposed to do in the time while it waits for the server to report that it's not a real collision?
Normally, a game has a pattern more or less like this: Client says "I'm moving to XYZ", and starts simulating locally to cover the network latency, and shows the move to the user, assuming the move will be OK. Eventually, the server confirms the move (or well, does not).
In this case, the server's reply might very well be: "Move confirmed. Oh by the way, you stepped on a trap".
In real life, when you step on a land mine, there is a fraction of a second while you're already lifting your foot again before you realize the "click", and then the mine only goes off half a second or so later. That seems to be a "works perfectly OK" method of building land mines. They wouldn't do that if it didn't work. I'd assume nobody will find a similar (indeed much shorter) delay disturbing or even immersion-breaking in a game.