libsecp256k1

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 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 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 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.

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 commit tightens a test suite for the secp256k1 cryptographic library. It adds checks to ensure that recoverable signing and signature conversion succeed before using their outputs. It does not change the library's actual signing or verification code, so it does not fix a live security bug in production software. It is a defensive improvement to testing.

This change fixes a small but real flaw in the MuSig test code. Previously, two test helper functions called internal loading/summing routines and then checked whether the results were the special 'point at infinity' value. Because the input buffers were already initialized to infinity, a failed load or sum could still make the infinity checks pass, so the test would not actually detect a broken implementation. The patch adds explicit success checks so the test fails if those routines return an error. This only affects test code, not the cryptographic library used by real Bitcoin transactions, so it does not create a direct security vulnerability in production software.

This change is inside the library's test code, not the actual cryptographic code used by applications. It makes two test setup steps verify they succeeded before using their results. Previously the test could have continued with invalid data if a load failed, which would make the test less reliable but does not create a vulnerability in the library itself.

This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, which could hide bugs during testing but does not change the production library behavior or introduce a direct vulnerability in running software.

This is a one-line change to a test file in the secp256k1 cryptographic library. It makes an existing exhaustive test stricter by requiring a function to report success before checking its output. It does not change any production code and is not a security fix for a vulnerability.

This commit only adds a changelog entry describing a new 'silentpayments' feature that was already added to the project. It changes no code, no build files, and no configuration. There is no security issue in this commit itself.

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 adds a debug-only safety check inside a Bitcoin cryptography library. It verifies that when an x-only public key (a compressed public key format that omits the Y coordinate) is saved, the internal representation has an even Y value, as the protocol definition requires. The check only runs in VERIFY builds and does not change production behavior. It is a defensive invariant, not a fix for a known exploitable bug.

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 fixes a bug in Bitcoin's silent payments scanning code. When a wallet scans a transaction for outputs it can spend, a performance shortcut could accidentally skip over a labeled output and report a plain (unlabeled) version instead. The fix makes the scanner check pending labeled candidates before accepting a direct unlabeled match, restoring the intended 'first match wins' behavior and preserving label metadata.

This commit is a simple code cleanup: it moves an existing block of label-scanning logic into a separate helper function without changing what the code actually does. There is no security fix or behavior change visible in the diff.