What libraries for secp256k1 have been used for bitcoin in the past?

[Anonymous Kid]

Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?

[1715463244]

1715463244

[1715463244]

1715463244

[1715463244]

1715463244

[1715463244]

1715463244

[darosior]

Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?

Hi,

To answer the question in the title : since 0.10, bitcoin-core uses its own implementation of secp256k1 : https://github.com/bitcoin/bitcoin/tree/v0.10.0/src/secp256k1 (BIP66). It previously used OpenSSL.
To answer the question in the post :

Is it possible that at least one of them had an exploit in them?

A bug in OpenSSL which could have caused a consensus failure in Bitcoin is what accelerated the move to using libsecp.

Making all of the transactions/addresses sent during that period vulnerable to attack?

How ?

[Coding Enthusiast]

It depends on which implementation of bitcoin you have in mind when you ask this question.

For example blockchain.com (.info) had a bug in one of their wallets (I believe it was the Android wallets) where they used random.org to generate k values and one day random.org changed their API and people lost money because it revealed their private keys!

bitcoin-core (QT) used to use OpenSSL library which had exploitable bug with its DER encodings which could be exploited and cause a fork, no keys were at risk though. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html

There was another "exploit" in the way mathematics of elliptic curves work where you could replace s in a signature with -s (malleability) which would have changed the hash. Now we enforce low s values only. No keys were at risk here either. https://en.bitcoin.it/wiki/Transaction_malleability#Signature_Malleability

[Anonymous Kid]

It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.

How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key?

[Coding Enthusiast]

It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.

How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key?

Not necessarily since it can be a random number inside (0<k<n-1). It can also be deterministic in which case it is not exactly hash of the private key. If you are using a deterministic k then it is calculated using HMAC with an appropriate hash function (SHA256 in our case) with private key as HMAC's key.

If there is a problem with implementation and you are not finding a random k and reuse the same value more than once, it is possible to calculate the private key from that.