Paragraph 1
The initial version of the Bitcoin client was shipped using the widespread OpenSSL library for signing and verifying transactions. Relying on a third-party library sounded reasonable, but this choice turned out to be problematic later due to inconsistencies in the signature parsing code. The issue was later fixed by BIP66, which ensured a strict encoding of ECDSA signatures, and the OpenSSL dependency was replaced with libsecp256k1 in Bitcoin Core v0.12 (2016). Sometime in 2012, Bitcoin Core developer Pieter Wuille, a.k.a. ‘sipa’, stumbled upon a bitcointalk thread by Hal Finney.
Paragraph 2
The goal of libsecp256k1 is to provide the highest quality library for cryptographic operations on the secp256k1 curve, with the primary intent of being useful in the broader Bitcoin ecosystem. The API of libsecp256k1 is designed to be robust and hard to misuse, in order to prevent users from performing insecure operations that could lead to a loss of funds. Libsecp256k1 is written in C and doesn’t have any dependency on other libraries, so it only uses internal code written specifically for the project. As such it is designed to also run on constrained devices like micro-controllers, which are commonly used in hardware wallets.
Paragraph 3
From very early on, libsecp256k1 had a strong focus on quality assurance that was continuously improved and honed over the years. There is a special form of assurance called ‘exhaustive testing’ that exercises the functionality of the library for the whole space of possible values on the curve. Because the actual secp256k1 curve has ~2^256 points, a smaller but similar curve is used for exhaustive testing to keep execution time reasonable. An important part of testing is ensuring constant-time behavior, which is especially relevant for signing.
Paragraph 4
Shifting our focus from QA to new features, one of the major milestones within the last decade in libsecp256k1, and in the Bitcoin protocol in general, was the introduction of Schnorr signatures. Being an essential part of the Schnorr Taproot soft-fork activated in late 2021, they offer many advantages over ECDSA signatures, including being provably secure under standard assumptions, more compact, and enabling a whole lot of other constructions on top like key and signature aggregation for more efficient multisignature schemes. Both the specification in BIP340 and implementation was created by the current three maintainers of libsecp256k1, Pieter Wuille, Jonas Nick and Tim Ruffing.
Paragraph 5
It goes without saying that verifying digital signatures is one of the most important and security-critical code paths of the Bitcoin consensus engine. Fast signature verification is also critical for both fast transaction and block propagation, and speed-ups the Initial Block Download (IBD) for new participants in the network. We have already mentioned earlier the ~5x speedup when libsecp256k1 replaced OpenSSL for the first time about ten years ago.
Paragraph 6
Over time, further performance improvements were implemented, and a recent investigation shows that libsecp256k1 is now about ~8x faster than OpenSSL for ECDSA signature verification using the most current version of each. So far we have focused on the verification functionality of libsecp256k1, being the most crucial for performance of node runners and miners. The other side of the coin is signing, i.e. the process of creating a digital signature for a transaction in order to spend funds.
Paragraph 7
What makes this process delicate is that secret key material is involved. Libsecp256k1 tries to combat against so-called ‘side-channel attacks’ by avoiding data-dependent branches, i.e. instances where different pieces of code are executed depending on what data is fed into it. This is not just a theoretical concern, but has happened more than once, requiring patches to be shipped (e.g. releases 0.3.1 and 0.3.2).
Paragraph 8
In 2014, Pieter Wuille and Gregory Maxwell were already working on an extensive test suite for the library. This revealed a case where OpenSSL gave a wrong result when squaring a number, a serious security relevant bug filed as CVE-2014-3570. Mostly by accident, Gregory Maxwell discovered a different variant of Bernstein and Yang’s algorithm with even lower bounds, leading to another significant speedup both for signing and verification.
Paragraph 9
The correctness (safety) of the ‘safegcd’ implementation has been formally verified using a special theorem proving software called Rocq (formerly named Coq) and the Verifiable C program logic. This impressive work was done by Russell O’Connor and Andrew Poelstra, who state that the entirety of libsecp256k1 could be verified in the same way. We have now shown that libsecp256k1 is primarily used for creating and verifying digital signatures in Bitcoin transactions, taking great care to do so in the safest and most efficient way possible, but it doesn’t stop there.
Paragraph 10
Whenever other proposals are put forward that involve cryptographic operations on the secp256k1 curve and are seen as beneficial for the Bitcoin ecosystem, the chances are good that the necessary code is considered in-scope for the library. There is also an ongoing effort to add a new module for Silent Payments, a privacy-preserving static reusable address that doesn’t need interaction before payment between sender and receiver. Let’s see what the next 10 years of development in libsecp256k1 will bring! Readers interested in libsecp256k1 are encouraged to take a look at secp256k1lab, a Python implementation of the secp256k1 curve that is intended for prototyping and experimentation.
Leave a Reply