Does secp256k1 have any known weaknesses? I am wondering whether there are any properties of the curve which would technically make it easier to attack than any other curves of 256 bits in size.

I have heard that being a Koblitz curve, it has a few bits weaker security than some other curves of the same size - I was wondering if anybody has a source for a proof (or sketch proof) of this fact if it is true, and for any other properties that may make the secp256k1 considered weaker.

EDIT: I have found this website http://safecurves.cr.yp.to/index.html which states that the curve does NOT satisfy all of the safety requirements for that website - however I am unable to understand the parameters under which it is considered not safe, and explanation on this would be nice too thanks :)
secp256k1 fails the following SafeCurves criteria, but it doesn't matter for Bitcoin's use of secp256k1:


CM field discriminant.
secp256k1 is a Koblitz curve that admits a fast endomorphism for speeding up scalar multiplications.  There is no particular vulnerability here: the same speedup you get in computing with secp256k1, an adversary gets in trying to break it, but that won't, in itself, render an infeasible attack feasible.  (This is what the ‘few bits weaker security’ refers to.)

SafeCurves conservatively rejects this because it is an additional structure that could be the foundation of future breakthroughs in cryptanalysis, but nobody has made that breakthrough and we have little reason to suspect it's going to happen sooner than any other unpredictable cryptanalytic breakthroughs.
Ladders.
secp256k1 does not admit the fast Montgomery ladder to compute $x$-restricted scalar multiplication in constant time; it does admit the much slower Brier–Joye ladder.

Of course, you can compute fast scalar multiplication in variable time, which exposes you to timing side-channel attacks.  This creates a conflict between fast implementations—everyone notices when things run slowly—and secure implementations—which nobody notices until their money is gone.  The SafeCurves criteria reject such conflicts that encourage performance or security, in favor of designs that encourage performance and security.

This is relevant mainly for applications doing Diffie–Hellman, but Bitcoin itself does not use secp256k1 for Diffie–Hellman, though Lightning does; Bitcoin itself uses secp256k1 only for ECDSA signatures.  (Conceivably, it would also be relevant for applications using exotic signature schemes like qDSA, but Bitcoin is not one of those.)
Completeness.
secp256k1 does not admit the fast complete Edwards formulas to compute elliptic curve addition in constant time; it does admit the much slower complete Weierstrass formulas to compute elliptic curve addition in constant time.

Of course, you can compute fast incomplete addition in variable time with conditionals, which exposes you to timing side-channel attacks; or you could compute fast incomplete addition in constant time with carefully chosen arithmetic that has the same effect as conditionals, which takes more effort to design and audit.  This creates a conflict between fast implementations, secure implementations, and easy implementations, which SafeCurves criteria avoid.

Fortunately, it seems that pretty much everyone who matters in the cryptocurrency world has recognized that this particular kind of security (as opposed to, e.g., economic security from equitable wealth distribution) is important, and now uses libsecp256k1 to very carefully compute secp256k1 curve arithmetic in constant time at a reasonable speed. So this poses more of a danger for the victims of novice implementors in novel scams; as long as you use libsecp256k1 and don't try to rewrite it at home, this doesn't pose a security problem.