libsecp256k1

This commit only updates documentation comments and an example error message in the silent payments module. It does not change any executable code, cryptographic calculations, or security behavior. The changes clarify when the output-creation function can fail and add internal explanatory notes for future maintainers.

This commit fixes an infinite-loop bug in the RFC6979 nonce generation code used for creating cryptographic signatures. If a caller asked for attempt number UINT_MAX (the maximum value of an unsigned integer), the old loop would generate that nonce but then keep going forever because the loop counter would wrap around to zero and never exceed the target. The fix generates the nonce first, then checks whether the requested attempt has been reached and exits. This is a reliability/correctness bug in a critical cryptographic path, though it requires a caller to deliberately request UINT_MAX to trigger.

This commit only changes documentation comments in a header file. It removes a recommendation that callers shuffle transaction outputs before scanning, and instead clarifies that outputs should be passed in their original transaction order. There is no code change, no security fix, and no vulnerability being addressed.

This commit only adds new test code. It extends the project's constant-time test suite to also exercise the silent payments module, ensuring that secret key material is not accidentally leaked through timing side channels during those operations. There is no change to the actual cryptographic library code that users rely on.

This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient is being paid on the blockchain. The change is a normal, well-documented feature addition with no indication of a security bug or vulnerability fix.

This commit is purely a build-system and header-file skeleton for a new Silent Payments (BIP352) module. It adds configuration options, dependency checks, and empty placeholder files, but contains no actual cryptographic code or implementation. There is nothing here that could introduce a security vulnerability.

This commit adds new public API functions to the silentpayments module of libsecp256k1 to support recipient-side labels for BIP352 silent payments. It is a feature addition, not a security fix or vulnerability patch. There is no evidence in the commit or supplied references of any security defect, exploit, or incident.

This commit adds new code for receiving BIP352 Silent Payments in the libsecp256k1 cryptography library. It introduces functions that let a wallet scan a Bitcoin transaction to find outputs sent to it and compute the secret tweaks needed to spend them later. The change is a feature addition with extensive tests; nothing in the commit message or diff indicates a security bug fix or vulnerability.

This commit fixes the libsecp256k1 Silent Payments implementation so it respects the protocol-defined maximum of 2,323 recipients that share the same scan public key. Previously, the code had a TODO warning about unbounded scanning that could lead to quadratic runtime and possible missed outputs. Now, sending fails if any group exceeds the limit, and scanning stops at the limit. It also documents a recommendation to shuffle transaction outputs to improve worst-case performance.

This commit is a routine cleanup of compiler feature checks in the secp256k1 cryptographic library. It replaces a custom version-check macro with a simpler check for whether the compiler is GCC (or claims to be GCC, like Clang). The change does not fix a security bug and does not introduce a clear vulnerability; it removes support for very old GCC versions that are no longer targeted.

This commit removes an unused internal compiler-version-checking helper macro from the public header file. It is a cleanup change with no security implications. The commit message notes it is technically a breaking change for any external code that might have relied on this macro, but the authors do not expect such usage.

This is a defensive code cleanup in a Bitcoin cryptography library. It introduces a helper function that wraps a common three-step pattern when multiplying by the generator point, ensuring that temporary sensitive Jacobian coordinate data is always wiped from memory. The change reduces the chance that a future developer forgets to clear that temporary data, which could theoretically leak tiny fragments of secret key information through memory side channels. It does not fix a known active bug or reported vulnerability.

This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed, so there is no security impact.

This is a small defensive cleanup in Bitcoin Core's libsecp256k1 MuSig code. The function that generates a cryptographic nonce could, in rare error cases, leave a temporary copy of the user's secret key in memory instead of wiping it. The patch makes sure the secret key buffer is always cleared, even when the internal function fails. The actual failure path can only be reached if the API is misused (bad keypair or cache), so this is best-practice hardening rather than an active exploit.

This is a small code-quality change in Bitcoin Core's secp256k1 cryptographic library. It adds an explicit safety check confirming that a value converted from one internal format to another stays within the expected range, and it silences a compiler warning about an unused return value. The commit message frames this as avoiding a compiler warning, not fixing a security bug.

This commit adds a new public API that lets users of the libsecp256k1 cryptography library swap out the internal SHA-256 compression function at runtime, typically to use a faster hardware-accelerated version. The library checks that the replacement behaves like the real SHA-256 step before accepting it. The change itself is a feature addition, not a bug fix, and there is no evidence in the commit or supplied references that it addresses a known security vulnerability.

This commit is a large but purely structural refactor of the libsecp256k1 cryptographic library. It threads a new 'hash context' through every SHA-256, HMAC-SHA-256, and RFC 6979 operation so that a different SHA-256 compression implementation (for example a faster hardware version) can be plugged in later. The commit message explicitly calls it a 'mechanical change with no behavior change,' and the code keeps the existing software compression function as the default everywhere. There is no security bug or vulnerability visible in this patch.

This commit removes a temporary workaround in the project's CI Docker build file. The workaround had relaxed a PGP signature policy check so that an older LLVM repository signing key would still be accepted by Debian's package manager during automated testing image builds. Removing the workaround simply restores the normal, stricter policy. There is no direct security vulnerability in the project's own code, and no runtime software is changed.

This commit is a simple code cleanup: it introduces a standard ARRAY_SIZE macro and replaces repeated manual array-size calculations with that macro. It does not change any behavior, fix any bug, or alter any security-sensitive logic. There is no security issue here.

This commit fixes a bug in the ElligatorSwift-based ECDH key exchange function. The function was supposed to reject secret keys that are invalid (zero or greater than or equal to the curve order), but due to a one-character bug it only checked for zero keys and silently accepted too-large keys by reducing them modulo the curve order. The fix makes it reject both invalid cases, matching the behavior of the regular ECDH function. There is no evidence this was exploited or that it caused real-world harm, but it is a genuine cryptographic correctness issue.

This commit only adds new unit tests for an existing internal function that checks whether a number has overflowed the secp256k1 group order. It does not change any production code, cryptographic logic, or behavior that could affect users. The change improves test coverage but introduces no security issue.

This commit is a straightforward code cleanup: it removes unnecessary type casts in front of memory allocation calls like malloc. In modern C, casting the result of malloc is not needed and is generally discouraged. The change does not alter program behavior, fix a bug, or address a security issue. It touches mostly test and benchmark code, with only two small changes in production functions that create or clone a cryptographic context.

This commit only removes invisible trailing spaces at the ends of three lines across three source files. It does not change any program logic, function behavior, or security properties. There is no security relevance.

This commit changes a CI Docker build script so that an older SHA-1-based PGP signature from the LLVM apt repository is still accepted. It is a build-infrastructure workaround, not a change to the secp256k1 cryptographic code, and it does not introduce a vulnerability in the library itself.

This is a one-line documentation update in a header file comment. It adds the CMake equivalent of an existing Autotools build option so developers know how to enable external default callbacks when building with CMake. No code behavior changes.