rust-bitcoin

This commit changes a single timing parameter in the Bitcoin network rules code from a 64-bit integer to a 32-bit integer. The value represents the expected seconds between blocks. The change simplifies the code by removing casts, but it slightly reduces the maximum value that parameter can hold. For all real Bitcoin networks this is harmless because the value is small (600 seconds for Bitcoin mainnet, 120 in the example). There is no direct security fix or vulnerability being patched.

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 commit simply renames a function from XOnlyPublicKey::new to XOnlyPublicKey::from_secp because the old name was misleading. The underlying behavior is unchanged. There is no security vulnerability or fix here.

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.

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 adds a small performance helper method called as_inner() to the XOnlyPublicKey type and switches existing internal code to use it instead of a method that copies the key. There is no security issue here; it is a routine optimization to avoid unnecessary copying.

This commit only adds a changelog entry describing a previously released version (0.32.8). It does not change any source code, build scripts, tests, or documentation beyond the changelog file. The security relevance, if any, would belong to the earlier code change being documented (a BIP158 empty-query fix), not to this changelog-only commit.

This commit is a routine automated code-formatting run using the nightly version of rustfmt. It only changes whitespace, line breaks, import ordering, and other stylistic details across 24 files. No program logic, security behavior, or public API was changed.

This commit is a routine code cleanup in the project's fuzz-testing harness. It removes a small set of hand-written helper functions and replaces them with a standard library approach for splitting fuzz input into slices. There is no change to the actual Bitcoin library code that users rely on, and nothing in the commit suggests a security fix.

This commit only updates generated API snapshot text files that record what functions and types are publicly exposed by the Rust crates. It moves the CompactTarget type from the primitives crate to the units crate and updates the corresponding API listings. There are no code logic changes, no bug fixes, and no security-relevant behavior changes.

This commit is a routine code reorganization. It moves two helper functions that parse hexadecimal strings into a CompactTarget value from one internal module to another. The actual logic and behavior of the functions are unchanged, and no security issue is present.

This commit is a routine code reorganization: it moves the CompactTarget type (and its proof-of-work module) from one internal crate (`primitives`) to another (`units`), while keeping the same public API available through re-exports. There is no security bug being fixed and no behavior change visible to users.

This commit adds a test-only feature implementation that lets the fuzzing framework generate random CompactTarget values. It does not change any production logic, consensus rules, or security behavior.

This commit simply updates the version of the Rust nightly compiler used by the project's automated GitHub testing from one date to another. It changes only a single line in a CI configuration file and has no effect on the actual Bitcoin library code that users run.

This commit is a routine code-quality cleanup. It moves linting rules from an individual crate's configuration to the shared workspace configuration, adds missing documentation comments, fixes minor test-code style issues, and adds a missing import in test code. There is no change to runtime behavior or security-sensitive logic.

This is a routine code-maintenance commit. It moves lint (style and warning) settings from an individual sub-crate to the shared workspace configuration, cleans up some import statements, adds documentation comments, and swaps a few style idioms (like `copied()` instead of `cloned()`). There is no change to security-sensitive behavior, no bug fix, and no vulnerability patch.

This commit is a routine housekeeping change that moves lint (code style warning) settings from individual crates to a shared workspace configuration. It does not change any program logic, fix bugs, or alter security behavior.

This is a routine code cleanup in the ChaCha20-Poly1305 cryptography module. It moves linting rules from an individual crate to the shared workspace configuration, updates documentation formatting, and refactors how the Poly1305 key is copied from a keystream slice. The commit explicitly states the refactored code is semantically equivalent and produces the same machine code. There is no security-relevant behavior change.

This commit only changes how hash values look when printed in debugging output. Instead of showing just the raw hex string, the debug format now also includes the type name, like 'Txid(bitcoin_hashes::sha256d::Hash(...))'. It does not change any behavior that handles real bitcoin data, secrets, or network messages, and it introduces no security risk.

This commit only changes how hash values look when printed for debugging. It adds the type name (like 'Txid(...)') around the hexadecimal hash string so developers can more easily tell which kind of hash they are looking at. It does not change how hashes are compared, stored, serialized, or used in Bitcoin logic.

This commit is a routine internal dependency cleanup. The project had been re-exporting an unstable version of a hex-encoding helper crate, but its policy says the main crate must only re-export stable versions. The change swaps the public re-export to the stable version while keeping the unstable version as a private internal dependency for code that still needs it. There is no security bug being fixed here.

This change lets users of the library who don't use the standard Rust library ('no_std' environments, common in embedded or blockchain hardware) benefit from faster SHA-256 hashing via CPU-specific instructions. It adds an optional helper crate that detects CPU features in 'no_std' mode, similar to how the standard library already does it. There is no direct evidence in the commit that this fixes a security vulnerability; it is a performance and portability improvement.