rust-bitcoin

This commit simply removes unused `cmp` (comparison) imports from five hash algorithm files in the `hashes` crate. It is a cleanup change with no functional effect and no security relevance.

This commit is a routine automated code-formatting run by the rustfmt tool. It only changes whitespace, import order, line breaks, and other stylistic details across 23 files. No program logic, algorithms, or security-sensitive behavior was altered.

This commit only adds new test data and test code. It imports official NIST cryptographic test vectors for several hash algorithms and writes tests that compare the library's output against those known correct answers. There is no change to the actual hashing code, no bug fix, and no security-relevant behavior change.

This is a routine code cleanup in the project's hash functions. A single-block helper was renamed and adjusted so it can later accept multiple blocks at once. The actual hashing math and behavior are unchanged, and the commit message explicitly says it is only refactoring with no logic changes.

This is a routine internal code cleanup in the project's hash-function code. It changes how a low-level helper function is called so it takes the hash state and data block as explicit arguments, rather than reading them from a surrounding object. The commit message and diff show no change to the actual hashing math or results. There is no security issue here.

This commit only adds and improves documentation comments for error conditions in the cryptographic key module. No code behavior, logic, or security properties were changed. It is a documentation-only change.

This commit fixes a bug in how the library reads Bitcoin public keys from raw bytes. Previously, when a caller said the key was 'compressed', the code did not verify that the first byte was a valid compressed-key prefix (2 or 3). That meant invalid or even attacker-chosen prefix bytes could be accepted for compressed keys, while uncompressed keys were already checked. The fix now rejects any compressed key whose first byte is not 2 or 3, matching the Bitcoin protocol rules.

This commit fixes a documentation comment for a Rust function. The comment previously said the function returned one type of private key object, but it actually returns a different, lower-level secret key type. There is no code behavior change and no security risk.

This is a code cleanup commit in the rust-bitcoin library. It replaces old transaction-encoding helper functions with newer equivalent ones inside the signature-hash (sighash) code. There is no direct evidence in the commit message or diff that this fixes a security vulnerability; it reads as a refactoring to use a newer internal API. However, because the change touches the exact code that computes Bitcoin transaction signatures, any accidental change to the bytes produced could break compatibility with the Bitcoin protocol or wallets, so it is in a security-sensitive area.

This commit fixes a bug where the Rust Bitcoin library incorrectly accepted 65-byte Taproot signatures whose final byte was 0x00. Under Bitcoin's BIP-341 rules, such signatures are invalid. Accepting them could let invalid transactions or signatures slip through, and it could break the library's own round-trip serialization (reading a signature in and writing it back out).

This commit fixes a bug in how X-only public keys were created from full public keys. An X-only key is just the X coordinate of a point, but a point can have an even or odd Y coordinate (parity). The old code always assumed even parity, which could silently produce the wrong key for odd-parity inputs. The fix preserves the actual parity from the source key.

This commit is a routine internal code reorganization. It moves the PublicKey and PrivateKey type definitions into a private 'encapsulate' module and re-exports them publicly. The fields were already private before this change, so no new access restrictions are introduced. There is no indication this fixes a security bug or changes behavior visible to users of the library.

This commit hides the internal fields of two key types (PublicKey and PrivateKey) so outside code can no longer read or change them directly. Instead, it provides read-only accessor methods. This is a normal defensive-coding change that improves encapsulation and makes future misuse less likely, but the commit itself does not fix a known active bug or vulnerability.

This commit hides the internal cryptographic key fields of PublicKey and PrivateKey from outside code, replacing direct access with controlled getter methods. It is a defensive hardening change that reduces the chance future callers will accidentally misuse or mutate the raw secp256k1 keys, but the commit itself does not fix a known exploitable bug.

This is a routine code cleanup in the rust-bitcoin library. It introduces new constructor functions named from_secp for creating public and private keys, and replaces direct internal field access with calls to those constructors. The old constructors are kept but marked as deprecated. There is no security bug being fixed here; the change is about improving code structure and preparing to hide internal details in the future.

This commit adds a best-effort memory-clearing helper for two cryptographic building blocks (HMAC and HKDF) in the rust-bitcoin library. It tries to overwrite secret intermediate data with zeros when those objects are destroyed, but the authors explicitly note this is not a guaranteed security fix because the Rust compiler may still leave copies of the data elsewhere in memory. The change is defensive hardening rather than a fix for a known exploitable bug.

This commit is a routine build-maintenance change. It removes an old shell script used to update dependency lock files and switches the project to using a new internal tool called cargo-rbmt for the same task. There is no change to the actual Bitcoin library code, no security fix, and no vulnerability introduced.

This commit adds new encoding and decoding machinery for a Bitcoin compact-block-relay data structure called HeaderAndShortIds. It preserves an existing safety check that prevents the combined number of short transaction IDs and prefilled transactions from overflowing a 16-bit limit. The change is mostly a refactor to use newer generic encoder traits; it does not appear to introduce a new vulnerability, but the author notes they do not fully understand why the overflow check guarantees safety of individual index differences.

This is a routine code cleanup that makes the crate's no_std setup consistent with other crates in the same repository. It does not fix a security bug and does not change behavior for users.

This commit is a routine API cleanup in the rust-bitcoin library. It removes an extra 'parity' argument and return value from functions that tweak public keys for Taproot, because the parity information can now be stored directly inside the XOnlyPublicKey type. There is no indication this fixes a security bug; it is a design simplification that may require downstream code to update how it calls these functions.

This commit is a routine API cleanup, not a security fix. It renames a method from `public_key` to `to_public_key` and removes a now-redundant `parity` argument because the parity information is already stored inside the x-only public key object. The code still produces the same public keys; callers just provide the parity in a different way. There is no indication this change fixes a vulnerability.

This commit is a routine API cleanup in the rust-bitcoin library. It changes a function so it returns only the x-only public key, instead of a pair of the key plus its parity bit. The parity information is now stored inside the key object itself, so callers no longer need to handle it separately. There is no security vulnerability here.

This commit changes the public API of XOnlyPublicKey::serialize() so it now returns both the 32-byte x-only key and its parity bit, instead of just the bytes. All existing callers inside the crate are updated to take only the first element (the bytes) and ignore the parity where it isn't needed. This is a routine API design change to expose extra information for users who need to fully reconstruct a key; it does not fix a bug or close a security hole.

This is a routine internal code refactor in a Bitcoin cryptography library. It adds a 'parity' field (a mathematical property of cryptographic keys) to the XOnlyPublicKey type, along with getter and setter functions. There is no indication this change fixes or introduces a security vulnerability.

This commit changes how a Bitcoin public-key type is serialized and deserialized when the optional serde feature is enabled. The old code automatically used the inner key type's format, which would break if extra data (such as key parity) is added later. The new code explicitly forwards to the inner type, keeping the wire format stable even as the wrapper type evolves. It is a hardening/preventive change rather than a fix for an active vulnerability.