rust-bitcoin

This commit adds a new, highly optimized way to compute a double SHA-256 hash on 64-byte inputs for 64-bit ARM processors (aarch64) using special CPU instructions. It is a pure performance improvement and does not change any public APIs or fix any known bug. There is no indication in the commit that it addresses a security vulnerability.

This commit only adds new unit tests for serializing and deserializing Bitcoin peer-to-peer address messages. It does not change any production code, fix a bug, or alter behavior. There is no security relevance.

This commit adds standard encoding and decoding support for a new P2P network message container (AddrV2Payload). It is a routine, vector-counterpart follow-up to a previous commit and does not appear to fix or introduce any security issue on its own.

This commit adds encoding and decoding support for a Bitcoin peer-to-peer network address message type (AddrV2Message). It changes how the 'services' field is decoded so it can accept very large numbers sent by some real Bitcoin nodes, instead of being limited to 32-bit values. The commit message says this is safe because the value is not used to allocate memory. There is no direct evidence in the commit that this fixes a security vulnerability, but handling unexpectedly large input values is a common place where bugs can occur.

This commit is a routine API cleanup: it renames a method on the PrivateKey type from public_key to to_public_key and keeps the old name as a deprecated alias. It does not change what the code does, only how callers spell the function name. There is no security bug being fixed.

This commit fixes a behavioral mismatch in a new Bitcoin data-decoding library. Previously, the new decoder would silently accept an empty byte slice as an empty list, while the older code rejected it because it lacked a length prefix. The change makes the new decoder reject empty inputs too, preventing subtle parsing differences that could affect how transactions or network messages are interpreted across versions.

This commit only updates generated API snapshot files that list what public types and functions exist in the rust-bitcoin 'primitives' crate. No actual source code was changed, and nothing in the commit message or diff suggests a security fix or vulnerability. It is a routine housekeeping change.

This commit only adds new test code to check that certain 'decoder' types can be created with a default value and a `new()` function. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit adds convenient ways to create certain Bitcoin data decoders (Default and new()) in the rust-bitcoin library. It does not change how data is parsed or validated, and there is no indication it fixes or introduces a security problem.

This commit is a purely cosmetic refactor of how hash types are declared in the rust-bitcoin library. It changes the internal macro syntax from a custom list of numbers and flags to something that looks more like ordinary Rust code. There is no change to the actual hashing behavior, output, or public API.

This is a routine automated code-formatting commit. It only changes whitespace, import order, line wrapping, and other stylistic details produced by the rustfmt tool. There are no functional changes, bug fixes, or security-related modifications.

This is a routine internal code cleanup in the rust-bitcoin peer-to-peer networking module. It swaps a general-purpose macro for a more specific one when building message encoders, because the newer macro can do everything the old one does and more. There is no user-facing behavior change and no security fix.

This is a routine library improvement that lets users ask 'how many bytes will this transaction input/output take up when encoded?' without actually encoding it. It adds a length method to two encoder types by switching to a macro that supports exact-size encoders. There is no security bug being fixed and no indication this change addresses any vulnerability.

This commit simply updates the version of the Rust nightly compiler used by the project's automated GitHub CI tests from one weekly nightly build to the next. It changes only a single version string in a configuration file. There is no code change, no bug fix, and no security-relevant behavior change.

This commit simply bumps the version number of a CI linting tool (cargo-semver-checks) used in GitHub Actions from 0.46.0 to 0.47.0. It changes one line in a workflow configuration file and has no effect on the actual Bitcoin library code, runtime behavior, or security.

This commit is a routine cleanup of how optional dependencies are declared in three Rust package configuration files. It changes feature flags to use the modern `dep:` syntax and updates comments to be clearer. There is no change to actual program logic, no security fix, and no vulnerability.

This commit simply updates a single version number in a CI configuration file from Rust compiler version 1.93.1 to 1.94.0. It changes no application code, no cryptographic logic, and no user-facing behavior. There is no security relevance.

This commit only updates a generated text file that lists the public API surface of the crate. No actual source code, logic, or behavior changed. It is a documentation/tracking update, not a security fix or functional change.

This commit adds a new helper module that lets Rust Bitcoin types be serialized and deserialized using Bitcoin's standard binary encoding, exposed through the popular serde serialization framework. It is a feature/refactoring change: it introduces a cleaner way to get the same behavior that previously required more verbose code. There is no indication in the commit that it fixes a security bug or vulnerability.

This commit is a routine API refactor in the rust-bitcoin library. It splits the old PrivateKey type into two parts: a simpler PrivateKey that only stores the secret key and compression flag, and a new WifKey type that pairs a PrivateKey with a Bitcoin network for WIF import/export. The change removes the network field from PrivateKey and moves WIF-specific parsing, serialization, and formatting onto WifKey. There is no security fix here; it is a design cleanup to make the key types more general-purpose.

This commit removes a line from a code example that printed a randomly-generated private key. The example now only prints the Bitcoin address. It is a documentation/example cleanup, not a fix for a software vulnerability in the library itself.

This change makes two helper libraries (serde and arbitrary) publicly visible from several rust-bitcoin crates. It is a dependency-management convenience for downstream developers and does not fix or introduce any security vulnerability.

This is a routine performance cleanup, not a security fix. It removes an unnecessary intermediate memory allocation when converting a Bitcoin script to a hex string by using an iterator directly. There is no change to behavior, parsing, validation, or cryptographic handling.

This change relaxes a Rust type-system restriction so a particular byte-iterator helper can work with trait objects and slices, not just fixed-size types. It is a routine API ergonomics improvement with no security relevance visible in the commit.

This commit only changes test code. It adds a configuration gate so that certain cryptography specification tests are skipped when the code is built with a special fuzzing flag. The fuzzing flag intentionally disables encryption to make fuzz testing easier, which naturally causes those spec-compliance tests to fail. There is no change to production code and no security vulnerability is being fixed.