<p>I think the boundary between libsecp256k1 and Bitcoin Core is pretty clear: everything that involves operations on private or public keys is in libsecp256k1.</p>
<p>Of course, in theory, anything can be anywhere, but I don't think there is much leeway here. In fact, I think recently the intention has been to go the other way, and expand slightly what is in libsecp256k1. In particular, there are currently key-tweak operations in libsecp256k1 (both on private and public keys), but things like the actual BIP32 derivation logic (including hashing etc.) and the taproot key tweaking and verification thereof are in Bitcoin Core, building on libsecp256k1's tweaking API. I think that at some point we'd like to have BIP32 and Taproot-specific APIs in libsecp256k1 instead, as we aim to have APIs there that are high-level and hard to misuse.</p>
<p>Of course, libsecp256k1 isn't just used by Bitcoin Core, so even if there was a desire to go the other way (and move some logic to Bitcoin Core), we wouldn't necessarily be able to do that, as there may be other users of the library that could be depending on said hypothetical functionality.</p>

CC BY-SA 4.0
2022-07-13T18:44:00.010Z
2022-07-13T19:27:44.900Z
2022-07-13T19:27:44.900Z
Pieter Wuille
<p>In this <a href="https://bitcoin.stackexchange.com/questions/114437/why-int128-in-secp256k1">question</a> on libsecp256k1 Pieter Wuille stated:</p>
<blockquote>
<p>libsecp256k1 provides implementations for all kinds of operations that involve private keys, public keys, or both. That includes key generation (computing public key given private key), key derivation (e.g. BIP32), as well as signing and verifying digital signatures (ECDSA, since recently also BIP340 Schnorr)</p>
</blockquote>
<p>In the same vein as <a href="https://bitcoin.stackexchange.com/questions/113863/in-future-will-multiple-widely-used-implementations-around-libbitcoinkernel-be-a">libbitcoinkernel</a> attempting to define what is consensus and what isn't is there code in libsecp256k1 that isn't strictly related to secp256k1 operations (and maybe isn't consensus critical e.g. wallet) and could/should be moved to the Core codebase? Or is there a clean separation (as clean it can be)? Examples if they exist would be great.</p>

<bitcoin-core-development><consensus><secp256k1>
Is there code in libsecp256k1 that theoretically should be moved to the main Core codebase?
Michael Folkson
# Is there code in libsecp256k1 that theoretically should be moved to the main Core codebase?

(Asked by: username_0 on 2022-07-13)

In this [question](https://bitcoin.stackexchange.com/questions/114437/why-int128-in-secp256k1) on libsecp256k1 username_1 username_1 stated:

> libsecp256k1 provides implementations for all kinds of operations that involve private keys, public keys, or both. That includes key generation (computing public key given private key), key derivation (e.g. BIP32), as well as signing and verifying digital signatures (ECDSA, since recently also BIP340 Schnorr)

In the same vein as [libbitcoinkernel](https://bitcoin.stackexchange.com/questions/113863/in-future-will-multiple-widely-used-implementations-around-libbitcoinkernel-be-a) attempting to define what is consensus and what isn't is there code in libsecp256k1 that isn't strictly related to secp256k1 operations (and maybe isn't consensus critical e.g. wallet) and could/should be moved to the Core codebase? Or is there a clean separation (as clean it can be)? Examples if they exist would be great.

**Tags:** bitcoin-core-development, consensus, secp256k1


---

## 1 answers

### Answer by username_1 on 2022-07-13. Score: 5 | Accepted answer

I think the boundary between libsecp256k1 and Bitcoin Core is pretty clear: everything that involves operations on private or public keys is in libsecp256k1.

Of course, in theory, anything can be anywhere, but I don't think there is much leeway here. In fact, I think recently the intention has been to go the other way, and expand slightly what is in libsecp256k1. In particular, there are currently key-tweak operations in libsecp256k1 (both on private and public keys), but things like the actual BIP32 derivation logic (including hashing etc.) and the taproot key tweaking and verification thereof are in Bitcoin Core, building on libsecp256k1's tweaking API. I think that at some point we'd like to have BIP32 and Taproot-specific APIs in libsecp256k1 instead, as we aim to have APIs there that are high-level and hard to misuse.

Of course, libsecp256k1 isn't just used by Bitcoin Core, so even if there was a desire to go the other way (and move some logic to Bitcoin Core), we wouldn't necessarily be able to do that, as there may be other users of the library that could be depending on said hypothetical functionality.


---

