libsecp256k1

This commit fixes an integer overflow bug in the library's internal scratch-space memory allocator. If a caller requested a scratch space with a size near the maximum possible value, adding the allocator's own bookkeeping header could wrap around to a tiny total size. That tiny allocation would then be used as if it were huge, potentially causing memory corruption. However, the scratch-space API is no longer exposed to users, so normal applications cannot trigger this.

This commit is a pure code cleanup: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several related files and moves the asterisk in pointer declarations from the left side to the right side (e.g., 'type* arg' to 'type *arg'). No behavior changes, no bug fixes, and no security fixes are present.

This commit fixes a low-level arithmetic overflow check in a special internal memory-pool helper called 'scratch space'. Because the scratch API is no longer exposed to users, the bug cannot be triggered by normal callers today. The change adds a guard so that an impossibly large requested size does not silently wrap around and produce a smaller memory allocation than intended.

This commit fixes test-suite bugs, not the cryptographic library itself. Several test cases were using outputs from functions without first checking whether those functions succeeded. In rare cases a failed setup step could leave a value that accidentally passed a later check, making the test look successful when it shouldn't. The patch adds result checks so tests fail loudly if a setup step fails. There is no direct security risk to users of the library.

This commit is a straightforward code cleanup: it removes a tiny internal helper function called secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no security bug is fixed or introduced.

This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cryptographic, or build-logic changes that affect security.

This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cryptographic, or build-logic changes that could affect security.

This commit is a routine release preparation for libsecp256k1 version 0.8.0. It only updates version numbers in build files (CMake and autotools) and finalizes the changelog. There are no code changes, no bug fixes, and no security-related modifications in the diff itself.

This commit strengthens the library's startup self-test for SHA-256 compression functions that users can plug in. It adds a more thorough 'smoke test' that compares the user-supplied function against the built-in one across many message lengths and memory alignments. The goal is to catch buggy or incompatible custom SHA-256 code early, before it silently produces wrong hashes. It is a defensive hardening change, not a fix for an active security hole.

This is a documentation-only commit that adds a changelog entry describing a previous code fix. The fix corrected a function in the ellswift module so it now rejects secret keys that are greater than or equal to the curve order, matching its documented behavior. The changelog explicitly states the old behavior is not considered a security issue because such keys are practically impossible to generate by chance.

This commit updates the project's release instructions to add a new step: creating a GPG-signed source-code tarball when making a release. It is a documentation-only change that improves release integrity and does not modify any code or fix a security bug.

This commit is a simple reorganization of the project's release-process documentation. It renames some sections, splits steps into clearer subsections, and adds minor wording clarifications (for example, reminding maintainers to manually review commits since the last release when writing changelog entries). No code, build scripts, cryptographic logic, or configuration defaults were changed.

This commit only makes minor wording edits to the project's release-process documentation. It changes a few phrases from 'PR is merged' to 'PR has been merged', adds 'a' before 'PR', and adds a new step reminding maintainers to merge release notes before announcing a release. There is no code change and no security relevance.

This commit simply adds a short 'Cleaning up' section to the project's release-process documentation. It describes administrative tasks like closing a GitHub milestone and removing a label after a release. There is no code change and no security relevance.

This is a documentation-only change to the project's release checklist. It adds a step telling release maintainers to attach the output of an ABI compatibility checking tool to release pull requests. There is no code change, no cryptographic change, and no security vulnerability.

This commit only adds a changelog entry describing a prior performance improvement (force-inlining field multiplication routines). It changes no source code, build scripts, or executable behavior. There is no security-relevant content in the diff.

This commit fixes a small but real privacy bug in the ElligatorSwift key-encoding helper. The code had wrongly assumed that the SHA-256 hashing routine wipes its internal buffer after feeding data in, so it marked the whole hash state as safe-to-leak and did not clear it. Because the buffer still held a copy of the secret key, that secret key could remain in stack memory longer than intended, especially when no extra random data (auxrnd) was provided. The patch narrows the 'declassify' to only the actual hash output/state and explicitly clears the SHA-256 buffer at the end, removing the leftover secret key from the stack.

This commit only updates the project's CHANGELOG.md file to document that a previously removed internal macro (SECP256K1_GNUC_PREREQ) was not part of the public API. It is a documentation-only change with no code modifications and no security relevance.

This commit only adds a documentation note to a public header file. It explains that certain auxiliary functions, when called directly by user code, will not use a user-installed SHA256 override callback because they do not receive a library context object. There is no code change, no behavior change, and no security fix.

This small change makes Bitcoin's cryptographic library treat two built-in functions (the default ECDSA nonce generator and the default ECDH hash function) as 'default' choices even when a caller explicitly passes them. The practical effect is that these built-in functions now receive the library context's hash function, which matters when the library is compiled with a custom hash implementation. Without this fix, a caller passing the same built-in function by name could accidentally bypass the context's hash function and use a different code path. There is no direct evidence in the commit of an exploitable vulnerability; it looks like a consistency/correctness fix.

This commit removes an old, renamed pointer called secp256k1_context_no_precomp from the secp256k1 cryptographic library. It had been marked as deprecated for over three years and was only an alias for the newer secp256k1_context_static. The change is a routine API cleanup, not a security fix, but any external code still using the old name will fail to compile or link after updating.

This commit removes an old, renamed function called secp256k1_schnorrsig_sign from the libsecp256k1 cryptographic library. It had been marked as deprecated for over three years and was simply an alias pointing to the newer secp256k1_schnorrsig_sign32. Any software still using the old name will fail to compile or link after this change, but the actual signing behavior is unchanged. There is no security vulnerability introduced by this cleanup.

This commit only updates the project's changelog file. It adds release-note entries for two previously merged changes and tweaks an existing entry for consistency. No program code was modified, so it cannot introduce or fix a security vulnerability on its own.

This commit fixes two test cases in the secp256k1 cryptographic library so they now verify that a public-key sorting function actually succeeds before checking its output. Previously the tests only inspected the sorted result and ignored whether the function returned an error. This is a test-hardening change, not a fix to the sorting function itself, and it does not create or fix a vulnerability in production code.

This is a small fix inside a test file for the silent payments module. It makes sure a function that converts a public key into bytes actually succeeds before comparing those bytes against expected test values. Previously, the test could compare stale or uninitialized bytes if the conversion failed, which could hide test failures but does not affect real wallet or network code.