Bitcoiners use a variety of phrases. “don’t trust, verify” You can also find out more about “not your keys, not your coins”Sometimes even saying that it’s “backed by math”. How is all this math actually put to use? Bitcoin’s design is based on a mathematical formula. Public-key Cryptography More specifically, digital signaturesThey are necessary to demonstrate ownership and do not require a central authority. It is less known what software makes the elliptic-curve math function and the efforts that are made to keep it secure, performant and with constant improvements. We’ll dive deep into the history and evolution behind “libsecp256k1″A library started as a hobby and evolved over time into an important part of the consensus rules that protect a multi-trillion dollars asset.
The Genesis
Satoshi selected an elliptic curvature named for unknown reasons. “secp256k1” Bitcoin’s digital signatures can be used to verify and create them. Initial versions of Bitcoin used the widely-used OpenSSL to sign and verify transactions. Software engineers may find it reasonable to rely on third-party libraries, especially when the library is as complex and domain-specific as an elliptic curve.
The inconsistencies of the code used to parse signatures made this decision problematic. This could lead to chain splits unintentionally in the worst-case scenario. OpenSSL, at that time, was not the right library to use for a system that relies on consensus like Bitcoin. BIP66 fixed the problem by ensuring that ECDSA was encoded in a way which would be secure. The OpenSSL dependencies were replaced by libsecp256k1 with Bitcoin Core 0.12, released early in 2016.1
The initial reason for starting the libsecp256k1 was mainly curiosity over a possible speedup. Around the end of 2012, Bitcoin Core Developer Pieter Wuille also known as. “sipa” I stumbled across a Bitcointalk thread from Hal Finney. (Known for having received the first Bitcoin payment in 2009, by Satoshi).
Subject: “Speeding up signature verification”The post described an optimization which would use a “so-called “endomorphism” (more specifically using the so-called GLV-method, Gallant-Lambert-Vanstone), something that only certain elliptic curves allow, secp256k1 conveniently being one of them. Hal Finney implemented it himself using OpenSSL, and it was even later submitted to Bitcoin Core as a public-review.2 It was still a good show.
The 20% acceleration was not combined in the end because of concerns over increasing code complexity as well as the fact that there is no assurance about the soundness of the cryptography.
Pieter Wuille decided to create a brand new library, starting from the beginning. The initial commit was made by the “secp256k1” The repository dates back to the 5th of March, 2013. The library verified the blockchain in one week (blocks height at the time was about 225000) and within a week it was also able to sign. After some testing and time, the library became ready to replace OpenSSL in Bitcoin Core. It was first used for the signing functionality.
Release v0.12, 2016, for ECDSA signature validation in consensus. It was worth the effort: According to Core’s PR description, using libsecp256k1 as signature verification is a good idea. “anywhere between 2.5 and 5.5 times faster”. This didn’t include, ironically, the previously mentioned endomorphism, because it was turned off as a default, due to concerns over patent violations. After the patent expires in 2020 (as enabled in release v0.20), it was activated, resulting in another 16% speedup.
Over time, several others contributed to the project. It was only natural that people who had worked closely with Pieter at Blockstream from the beginning, such as then-CTO Gregory Maxwell or researcher Andrew Poelstra, would be involved. Jonas Nick joined Blockstream in 2015 and Tim Ruffing a year later. Both were employed as Blockstream researchers, and have been maintaining libsecp256k1 since several years. Since they’re responsible for both specifying cryptographic
It is appropriate to refer to them as protocols. “full-stack cryptographers”Tim Ruffing is a man who likes to be called.
Cryptographers from the Bitcoin community have sometimes contributed.
libsecp256k1. Peter Dettman is a notable example. He was one of BouncyCastle’s maintainers, and he still comes up with performance improvements. His major contribution was the implementation of modular inversion by using the “safegcd” In 2021, the algorithm will be improved to improve safety based on a study by Daniel J. Bernstein & Bo-Yin Yang.
Why Re-invent the Wheel?
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–Bitcoin Core is simply the main client using it. To prevent insecure actions (e.g., performing unreliable operations), the API for libsecp256k1 was designed to be hard to abuse and robust. By rolling their own cryptographic scheme) which could result in a loss of money at worst. Focusing on only one elliptic curvature and limiting the functionality of its operations
The code, when it comes to Bitcoin, can be faster, simpler, and more reliable. This means a reduced maintenance burden, and a higher quality implementation. It is written entirely in C without any dependencies on other libraries. Only a few people know how to pronounce the word “only” Uses internal code that is written for each project. It is also designed to run on devices that are constrained, such as microcontrollers.
Measuring twice, cutting once
Early on, the focus of libsecp256k1 was on quality. Over time this has evolved and been improved. The testing code is now close to being 100% and it’s only possible for new modules to be merged when this standard has been met. There is another form of assurance, called “exhaustive testing”. This is done to demonstrate the capabilities of the library across the entire range of values that can be assigned on the curve. Since this is impossible on the real secp256k1 (2256) curve, it is done with a much smaller curve that has an order of only double digits. As we’ll see, a constant-time test is crucial for testing.
Schnorr – A whole new world
Schnorrs signatures, which were implemented in libsecp256k1, as well as the Bitcoin protocol itself, in the past decade, marked a significant milestone. Schnorr signatures are a key component of the Schnorr/Taproot software fork, which will activate in late 2021. They offer several advantages over ECDSA. Provably Secure The resulting scheme is smaller, faster, and more compact. It also allows for other structures to be built on top, such as key and signature aggregates, which can lead to more efficient multisignature systems. Both the specification in BIP340 and implementation was created by the current three maintainers of libsecp256k1, Pieter Wuille, Jonas Nick and Tim Ruffing.
The Network And Your Node Will Benefit From libsecp256k1.
Verifying digital signatures should be one (if not the) most important tasks in any security system. You can also find out more about the following:() The most important, and the security-critical code path of the Bitcoin consensus algorithm. Even if a locking script includes complex script paths and additional spending conditions, there will likely be at least one check of signatures to verify that the coin being spent was created by its owner. In order to perform this essential task, the code must be robust, thoroughly tested, and as performant as it can possibly be. It is important to have fast signature verification for transaction propagation and for block propagation. This also helps with the Initial Block Download for new network participants. For the first time, libsecp256k1 was 5x faster than OpenSSL ten years back. In time, performance was improved further. A recent study shows that libsecp256k1 can now verify ECDSA signatures 8x quicker than OpenSSL using their most recent versions.3
Don’t Sign the Wrong Way!
We have so far focused our attention on the verification capabilities of libsecp256k1, which are the most important for the performance of miners and node runners. It’s the flip side! The other side of the coin (no pun intended!) Sign up for our Newsletter, i.e. This is the process for creating a signature digitally to authorize a financial transaction. This process is made more delicate by the secret material that is used. In the worst-case scenario, a leak of this key material can lead to massive losses in funds. Special care must therefore be taken during implementation. The libsecp256k1 is designed to fight against the so-called “side-channel attacks” Avoid data-dependent branches by not using them. There are instances when different code pieces will execute depending on which data they receive. It is not a trivial task, and requires some additional effort when using modern compilers. “too smart” In the sense that we do not want them to compile our software to a resource-saving branch. It is not a hypothetical concern. This has occurred more than once and required patches to be sent out (e.g. This is a concern that has been raised more than once, requiring patches to be shipped (e.g. releases 0.3.1 & 0.3.2). A tool named “valgrind” This was initially designed for the purpose of debugging issues with memory. We can identify potential side-channel risks by using the tool to detect any code branching that operates on secret data.
Unintentionally leaving secret information in memory is another way it could leak. This may sound trivial but it must be done so that code optimizations during the compilation do not interfere. To prevent this, great care is taken.
Some Happy Accidents
During the course of developing the library, many interesting surprises have occurred. Pieter Wuille & Gregory Maxwell began working on the extensive library test suite in 2014. Verifying the behaviour of library functions against those of other implementations using special random inputs was one of the ways to increase the level of confidence. It was found that OpenSSL returned a false result for squaring numbers, which is a security-relevant bug.”Bignum squaring may produce incorrect results.”).
Pieter Wuille, in a second instance some years later proposed a method to compute a bound or limit on the number iterations required for the previous mentioned “safegcd” The algorithm is for computing modular inversions. It was possible to shrink the bounds, resulting in a quicker computation. It didn’t end there. Gregory Maxwell found a variant of Bernstein-Yang’s algorithm, with lower bounds. It was a total accident.
The correctness of (and safety) the “safegcd” Implementation has been verified formally using special software for theorem-proving called “Rocq” Formerly named “Coq”The. “Verifiable C” Programm logic.4 Russell O’Connor & Andrew Poelstra have performed an amazing job. According to them, the entire libsecp256k1 code could be tested in the same manner.
The Cryptography Industry is Still Growing
We’ve shown how libsecp256k1 can be used to create and verify digital signatures for Bitcoin transactions. This is done in the most secure and efficient manner possible. But it doesn’t end there. When other cryptographic proposals that are formalized as BIPs and that are seen to benefit the Bitcoin ecosystem are made, it is likely that they will be considered within the scope of this library. Given enough developer time to implement and review the proposal, it is likely that it will end up as a new release of libsecp256k1. It has happened in the past with ElligatorSwift, which was crucial for P2P communications between nodes to be encrypted. [see BIP324; discussed in-depth on here]MuSig2 is the latest key aggregation method based upon Schnorr’s signatures. It allows creating multi-signatures n on n in a privacy-preserving and space-efficient manner. It is currently being worked on to include a Silent Payments Module, which proposes a static address with no interaction required between the sender and recipient before payment. But there’s still more: Batch validation of Schnorr Signatures, DLEQ Proofs, Frost, etc. We’re looking forward to the 10th anniversary of libsecp256k1 development!
The secp256k1 implementation in Python is intended as a tool for experimentation, prototyping, and prototyping.5
Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!
It is the letter from the editor that appears in the most recent issue. Print This is the core issue of Bitcoin Magazine. Here’s an early preview of what the core issue will explore.
[1] https://gnusha.org/pi/bitcoindev/55B79146.70309@gmail.com/
[2] (#2061, https://github.com/bitcoin/bitcoin/pull/2061)
[3] https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087?u=thestack
[4] [https://www.arxiv.org/abs/2507.17956]
[5] https://github.com/secp256k1lab/secp256k1lab/
“This article is not financial advice.”
“Always do your own research before making any type of investment.”
“ItsDailyCrypto is not responsible for any activities you perform outside ItsDailyCrypto.”
Source: bitcoinmagazine.com
