rust-bitcoin

This commit simply moves an existing SHA256 midstate-to-engine conversion from one place in the code to another. The actual logic is unchanged; it is a code-organization refactor following a Rust API design guideline. There is no security fix or vulnerability here.

This commit is purely a code formatting cleanup. It removes blank lines, reorders some import/module declarations, and collapses a few trivial function bodies onto one line. There are no functional changes to how the software behaves, and no security implications.

This commit is a routine API refactor in the rust-bitcoin library. It changes the message-signing function so it accepts a higher-level PrivateKey reference instead of a low-level secp256k1 secret key, and moves the underlying signing logic into a new PrivateKey method. There is no indication this fixes a security bug; it is a design cleanup to hide internal cryptographic types from users and prepare for future API changes.

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 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 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 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 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 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 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 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 commit adds optional support for the `arbitrary` crate, a Rust fuzz-testing helper, across several data types in the rust-bitcoin library. It does not change normal runtime behavior; the new code is only compiled when the optional `arbitrary` feature is enabled. There is no direct security vulnerability in the diff, but it slightly expands the library's dependency tree and public API surface for users who opt into the feature.

This commit only adds a new unit test; it does not change production code. The test checks that parsing a malformed PSBT key with an impossibly small byte-size field returns a proper error instead of crashing. The underlying panic/underflow bug was already fixed in an earlier change, so this patch is a regression test rather than a fix.

This commit changes a GitHub Actions workflow so that a security linting tool called zizmor is installed at a fixed version (1.22.0) instead of the latest release. It is a routine CI maintenance change to prevent unexpected breakages when zizmor releases new versions. There is no indication it fixes or introduces a security vulnerability.

This commit simply moves a file called 'stable-version' from one folder to another within the project's CI configuration. The file contains a Rust compiler version number used by automated checks. There is no change to the project's actual Bitcoin code, no security fix, and no vulnerability introduced.

This is a minor code cleanup commit. It removes an unnecessary intermediate variable, updates a doc comment to match a previous API change, and removes an outdated comment in a test. There is no functional change and no security impact.

This commit adds convenience methods so that a Bitcoin keypair can sign messages directly, without callers having to reach into the underlying secp256k1 library. It is a code-cleanup and API-ergonomics change, not a fix for a known bug or vulnerability. The new methods wrap the same underlying signing functions that were already being used, so the cryptographic behavior is unchanged.

This commit changes how the library exposes a Bitcoin secret key pair internally. Previously, calling `to_inner()` made a full copy of the secret key data. The new `as_inner()` returns a reference instead, so the secret bytes are not duplicated in memory as often. This is a defensive hardening change: it reduces the number of copies of sensitive key material floating around in memory, which slightly lowers the chance that a secret key could leak through memory dumps, swap, or debugging. It is not a fix for an active bug or a directly exploitable vulnerability.

This commit is a routine code reorganization: it moves functions that parse Bitcoin script hex strings from the main `bitcoin` crate into the lower-level `primitives` crate. The old functions in `bitcoin` are kept as deprecated aliases so existing code keeps working. There is no security fix or vulnerability here.

This is a routine code-maintenance change. The developers replaced one way of reading hexadecimal strings with another, because the old helper tool (the `FromHex` trait) is being removed in an upcoming version of a dependency. The function being changed is already marked as deprecated, so it is not the preferred way to do things. There is no indication this fixes a security bug or introduces a vulnerability.