In what ways might a basepoint be compromised?

[Tllsldr]

This is a quote I found in this forum from gmaxwell

Yes, but G is security irrelevant for our normal usage in Bitcoin (and generally, except for some contrived examples— e.g. where I need to convince you that I don't know the discrete log of some nothing up my sleeve point X (X!=G), and I picked X long in advance and selected G so that I knew the discrete log of X, but this is contrived and isn't something that I can think of any reason we'd do in Bitcoin.

I couldn't find much literature on this so I asked chatGPT which explained to me (quite possibly incorrectly) that:

Under normal circumstances d * G = Q (where d is the private key, G is the basepoint, Q is the public key, '*' represents scalar multiplication.) But if you were aware of a deeper relationship, by design or otherwise, where s * H = G (s is a scalar in the range of 2-N, H is a valid point on the curve) This would allow you to solve any private key in the system instantly, no ECDLP required, because you can substitute in d * (s*H) = G and solve it algebraically.

So can someone tell me if this is correct or incorrect?

I have struggled for days trying to understand this. If someone could let me know, maybe even make a python example that uses an example basepoint with a hidden relationship to demonstrate how it would work. That would mean a lot to me and anyone else interested in the same thing.

Regardless of whether or not SECP256k1's basepoint was chosen with a hidden relationship in mind, those hidden relationships still exist theoretically right? It's just another interesting way of looking at ECDLP.

Thank you

[gmaxwell]

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.

[Tllsldr]

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.