I am working on a multiplayer 2D shooter to get the hang of networking. In general I am trying to make something like Alien Breed, except multiplayer.

I am using UDP (through Enet) for my networking, Server is running at 20Hz. I have implemented entity interpolation to smooth the movements (rendering 100-200ms in the past, didn't settle on the final value yet) and I have clientside prediction so that player's movement is instant. These parts work well so far.

I am trying to add a projectile weapon now (slow moving projectile). When player clicks the mouse button, I send a "PLAYER_WANTS_TO_SHOOT" packet to the server. Server creates a bullet object which will be broadcast to all players on the next server tick. The problem is, it takes roundtrip/2 time to get the PLAYER_WANTS_TO_SHOOT packet to the server, then some delay until the next tick, then roundtrip/2 time to get to the player and then I render everything 100-200ms in the past, so that's additional latency. By the time the client receives the position of the bullet he shot, he might be in a completely different spot, making the bullets away from the player, which is awkward. It's not an issue for other players shooting, because they are in the past, so the bullets will appear to come from them.

How to fix this issue? I imagine clientside prediction should be used somehow here, but if client was to control the bullet it allows him to cheat. Alternatively I could let the client create a fake bullet which is a visual only, while the real bullet and hit checking would be done on the server. Would that work?

Rendering 100ms in the past seems a bit pessimistic to me. You'll probably avoid all instances of not having data in time, at the price of everything seeming slow. I'd prefer to reduce that latency significantly at the cost of having to perform occasional extrapolation and potentially snap-back to correct things.

You can perform client-side prediction without being client-authoritative, which is basically the 'fake bullet' you speak of. The client produces a projectile, tells the server which direction it's travelling in, and the server can confirm or deny it, just like it would for player movement if you're allowing them to move without a 200ms delay. You can interpolate between the predicted trajectory and the corrected trajectory if necessary, and you can delay the actual client-side firing to some degree as well, covering it with animation and sound fx.

Definitely sounds like you've strayed too far away from lockstep in your zeal to make inherently slow software seem less slow for the user. Strayed so far that things stop working. While an arcade game can play faster and looser with physics than a simulation can, there are still limits as to how much you can fake. You're going to have to tighten it up some. When you have to start faking stuff because of other stuff you've already faked, you're building a house of cards - on a foundation of ethereal "sort of lockstep" physics.

IIRC, counter strike, which has become a model for twitch action networking, spawns a predicted client-side projectile, while messaging the server to spawn one. The message includes a timestamp so the server can actually rewind if necessary to insert the projectile into the simulation at the exact moment the client requested. To facilitate this the server obviously needs to buffer a lot of simulation state so that rewinding and replaying within the configured latency window is possible.