How can a basepoint be compromised?

I saw a quote from gmaxwell on this forum that got me thinking. I couldn't find much info on this topic, so I asked chatGPT for some help. It told me something like this (might be wrong though): Usually, you have d * G = Q (where d is the private key, G is the basepoint, and Q is the public key, with '*' being scalar multiplication). But if you somehow discover a deeper link where s * H = G (with s being a scalar in the range of 2-N and H being a valid point on the curve), then you could instantly figure out any private key without needing to deal with the ECDLP. You could just plug it into d * (s * H) = G and solve it mathematically. Can someone clarify if this is accurate or not? I've been struggling for days to wrap my head around this. If anyone could break it down, maybe even whip up a Python example with a basepoint showing this hidden relationship, that would be super helpful for me and anyone else interested in it. Even if SECP256k1's basepoint wasn't intentionally chosen with hidden relationships, those kinds of links could still theoretically exist, right? It's just another fascinating perspective on ECDLP. Thanks!

Chatgpt is really frequently bad, this is an example of it. Take any field element s on the finite field of the curve order P. Compute H = (1/s) *G.  Tada, you now have an "H" of the form in the example: s * H = G.  This doesn't have any security implication at all.  It's a relation easily computed for any element on the field of curve-order. The choice of G doesn't have any security relevance in any ordinary usage. It only has relevance in special and somewhat contrived usage.   E.g. I want to convince you that I don't know the discrete log of some point with respect to G.  So I do something like pick that point with sha256.  So you think "oh surely you can't know the discrete log of that, it was selected by a hash!" and that would be generally true unless G itself was generated based on this supposedly "nothing up my sleeve" point (causing the relationship between them to be known).   To avoid this risk any protocol that needs a nothing-up-my-sleeve point should construct it by using a hash that includes G, which proves (absent a hash collision) that G couldn't have been created as some multiple of the nums point. If this isn't making much sense to you it's because there are relatively few reasons to have a nothing up my sleeve point, and none when it comes to ordinary bitcoin usage.  They're required in some zero knowledge proof setups.

Thank you for the reply. it is making sense now. Even if I had knowledge of a relationship s * H = G ... Substituting d * (s*h)=Q and shuffling around still leaves you with Q' = d*H which is a ECDLP. I have heard that the NIST standards that define G don't give any reason why... and some have said "Oh look at that... they might know something we dont!" But from what you are saying... There's really nothing to know.