The privatekey -> pubkey function is “fine”. It isn’t a vector for being subjected to twist attack.

The pubkey you get back from this function will be on the curve as it’s internally munged to be. The risk is that it won’t “match” the private key that you provided. 

The attack specifically requires you not to verify a pubkey you’ve been given is on the curve.

> am I not using secp256k1 just because the library has a vulnerability?

Technically, yes 😂 in this case the bug is the library is not living up to its name 🤷 

niftynei

That's the `ParsePubKey` function. But if I am not using this function but provide my own bytes, then the `secp256k1` package does not make sure. At least that's how I understand this warning for the function [`PrivKeyFromBytes`](https://pkg.go.dev/github.com/decred/dcrd/dcrec/secp256k1/v4#PrivKeyFromBytes).

> WARNING: This means passing a slice with more than 32 bytes is truncated and that truncated value is reduced modulo N. Further, 0 is not a valid private key. It is up to the caller to provide a value in the appropriate range of [1, N-1]. Failure to do so will either result in an invalid private key or potentially weak private keys that have bias that could be exploited.

Also, bitcoin does not use the [github.com/decred/dcrd/dcrec/secp256k1/v4](https://pkg.go.dev/github.com/decred/dcrd/dcrec/secp256k1/v4) package. It uses [libsecp256k1](https://github.com/bitcoin-core/secp256k1) since it's written in C. LND however is written in golang and uses the aforementioned package.