Compact Schnorr signature? The commonly-used ECDSA signature consists of 2 scalars $(r,s)$. There's also a Schnorr signature. Given private key $k$, public key $C = [k]G$ and the message $M$:


Generate random scalar $k_1$
Calculate the $C_1 = [k_1]G$
Calculate the challenge $e = H(C_1 \mathbin\Vert M)$ where $H$ is a selected hash function
Calculate $k_2 = k_1 + e\cdot k$
Signature is $(C_1, k_2)$


The verifier then verifies that $[k_2]G = C_1 + [e]C$

Both schemes seem to be nearly equally secure. I like more the Schnorr's scheme, because it uses nothing more than just a common ECC arithmetics. However the drawback is that the signature is bigger: instead of 2 scalars it's now scalar + point (with 2 coordinates).

One way to solve this is to store the curve point in a compressed way: its $x$ coordinate and the sign bit, from which the $y$ coordinate may be recovered. But this requires extra calculations.

I thought about an easier way. Let's just store the $x(C_1)$—the $x$ coordinate, and the challenge formula should be adjusted to account only for $x(C_1)$.

The verifier should verify the following: $x([k_2]G - [e]C) = x(C_1)$. That is calculate the left-side curve point, take its $x$ coordinate and compare to the signature.

Is this a common practice? Is there a potential flaw in this scheme?
This would work, but note that your weakening verification (slightly). Instead of only $(C_1,k_2)$ being a valid signature, now also $(-C_1,k_2)$ is valid. If you want to do signatures by only using $x$-coordinates you can use the qDSA signature scheme, which indeed saves a few bits in the signature size and public key.

There is actually a more serious compression of Schnorr signatures, which I think is quite common. It is already described in Schnorr's original paper. Instead of having a signature $(C_1,k_2)$ we use $(e,k_2)$, where it actually suffices to have relatively small $e$ (say 128 bits for 128-bit security level). Now we can verify by computing $\bar C_1 = [k_2]G - [e]C$ and checking that
$H(\bar C_1\,||\,M) = e$. 

This leads to a 48-byte signature as opposed to a 64-byte one, so saves significantly more than a bit. A downside is that you cannot batch-verify signature anymore, though I don't know if that's actually used in practice.