rust-bitcoin

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.

This commit is a routine performance optimization. It rewrites how a Bitcoin transaction witness is built from an iterator so that it uses a single decoder pass instead of allocating many small temporary vectors. There is no indication of a security bug being fixed.

This commit adds standard encoding and decoding support for the Bitcoin P2P 'headers' message type in the rust-bitcoin library. It is a routine feature implementation with no visible security fix or behavior change to existing code paths.

This commit adds new serialization/deserialization code for a Bitcoin P2P message wrapper type called NetworkHeader. It is a routine feature addition that implements internal encoding traits so NetworkHeader can be used inside another message type (HeadersMessage). There is no indication in the commit of a security bug, vulnerability, or fix.

This commit changes how Bitcoin block headers received over the peer-to-peer network are parsed. Previously, the code would reject a headers message if the trailing byte (which indicates how many transactions follow) was anything other than zero. The commit introduces a wrapper type that accepts any value for that byte. The stated reason is future-proofing: if Bitcoin ever uses that byte for something useful, clients using this stricter library would be unable to follow the longest chain because they'd reject valid messages. There is no claim in the commit that this fixes an active security bug, and the change is framed as a protocol-compatibility improvement.

This commit only changes test code. It updates a handful of unit tests in the Merkle tree module to use a newer internal encoding helper (`encoding::encode_to_vec` / `encoding::decode_from_slice`) instead of the older `encode::serialize` / `encode::deserialize` helpers. No production code is modified, so it cannot affect the security of the library at runtime.

This commit adds new encoding and decoding machinery for a data structure called MerkleBlock in the library's peer-to-peer networking code. It is a routine feature addition that mirrors a similar change already made for PartialMerkleTree. There is no indication in the commit that this fixes a security bug or introduces a vulnerability.

This commit adds new serialization/deserialization code for PartialMerkleTree, a data structure used in Bitcoin peer-to-peer messages. It re-implements the existing bit-packing logic using a new internal encoding framework. There is no direct evidence of a security bug, but the change touches low-level binary parsing and could introduce subtle correctness issues if the new decoder does not exactly match the old behavior.

This commit only adds a new performance benchmark for the SHA256d hashing function. It does not change any production code, cryptographic logic, or user-facing behavior. There is no security issue.