rust-bitcoin

This commit is a routine maintenance update to the project's automated testing setup. It upgrades an internal tool called cargo-rbmt and moves its configuration from separate files into each crate's Cargo.toml package metadata. It also changes how nightly and stable Rust compiler versions are tracked, storing them in the workspace Cargo.toml instead of separate version files. There are no changes to the actual Bitcoin library code that users depend on, and no security-relevant behavior is modified.

This commit only updates generated API snapshot text files. It removes lines that list certain error-conversion functions from the public API surface, but it does not change any actual Rust source code, logic, or behavior. There is no security-relevant change visible in the diff.

This commit removes automatic conversion traits (From implementations) that let sub-errors be silently turned into parent errors. It replaces them with explicit error wrapping at each call site. This is a code-quality and API-clarity change, not a security fix. There is no evidence in the commit message or diff that it addresses a vulnerability, exploit, or bug that could affect users.

This commit is purely a code-formatting cleanup. It removes blank lines, reorders imports, and lets an automated formatter rewrap a few lines. There are no functional changes to how the software behaves, and nothing in the diff suggests a security fix or vulnerability.

This commit adds a new helper method, to_secret_bytes, to the PrivateKey type in the rust-bitcoin library. It returns a private key as a fixed 32-byte array instead of a variable-length vector. The existing to_secret_vec method is rewritten to use the new helper. There is no visible security fix or behavior change; it is a routine API convenience addition.

This commit only adds new automated tests that check whether Bitcoin-style cryptographic keys can be converted to and from the underlying secp256k1 library's key types. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit simply changes an existing internal helper function to be publicly usable and adds documentation and examples. It does not fix a bug, change behavior, or introduce any new security-sensitive logic. The function already existed and behaved the same way; only its visibility changed from private to public.

This commit adds two new helper methods, serialize_compressed and serialize_uncompressed, to the bitcoin::PublicKey type. Previously, users had to reach into the underlying secp256k1 library to serialize a public key. The change simply wraps that existing behavior in a more convenient API and updates internal callers to use the new methods. There is no indication of a security bug being fixed.

This commit adds a new performance-oriented function for computing many double-SHA256 hashes at once, with a special two-at-a-time path for ARM CPUs that support SHA2 hardware instructions. It also exposes that function as a new public API. There is nothing in the diff that fixes a bug, checks bounds incorrectly, or introduces an obvious security flaw; it appears to be a routine optimization and API addition.

This commit is a performance optimization for SHA256 double hashing on 64-bit ARM processors. It rewrites a single-hash ARM hardware-accelerated routine to compute two independent hashes at the same time, filling otherwise wasted CPU cycles. There is no security bug being fixed and no new attack surface introduced; it is purely a speed improvement.

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

This commit only updates generated API snapshot files (text listings of public types and functions) to reflect a new CompactSizeU64Decoder type and a moved CompactSizeEncoder module path. No actual source code, logic, or behavior changes are present in the diff, so it has no security relevance on its own.

This commit is a pure code reorganization: it moves the compact-size integer encoder and decoder into a new dedicated file/module. The public API is unchanged, the logic is unchanged, and no security-relevant behavior is modified.