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

This commit simply removes two outdated lines from a code comment. The removed text incorrectly claimed that the function always sets an even parity, but the function actually accepts a parity argument supplied by the caller. There is no code change and no security issue.

This commit is a routine dependency cleanup. It removes the external hex_lit crate and switches test/example code to use built-in hex macros from the project's own hex-conservative crate. There is no user-facing behavior change and no security fix or vulnerability introduced.

This commit is a routine API rename with no security bug. It renames functions in the Rust Bitcoin library that handle private key bytes so their names include the word 'secret' (for example, 'to_vec' becomes 'to_secret_vec' and 'from_byte_array' becomes 'from_secret_bytes'). The goal is to make it more obvious to developers when they are working with sensitive secret material. The actual behavior of the code is unchanged.

This commit is a build-system cleanup, not a security fix. It removes crate-wide switches that made entire Rust sub-crates disappear when the 'alloc' feature was off, and instead marks individual functions and types as requiring 'alloc'. The stated reason is to fix linking problems in no-alloc builds, not to patch a vulnerability. There is no evidence in the commit of an exploitable bug.

This commit fixes a bug in how the library reads PSBT (Partially Signed Bitcoin Transaction) keys. A recent change accidentally made it possible for a malformed input to cause an arithmetic underflow when calculating how many bytes of key data remain. In debug builds that would panic (crash); in release builds it could wrap around and behave incorrectly. The fix uses a safe checked subtraction and returns a proper parsing error instead.

This commit is a maintenance change that switches the project's fuzz testing framework from Honggfuzz to libfuzzer (cargo-fuzz). It updates build files, CI configuration, documentation, and fuzz target source files to use the new framework. There is no change to the actual Bitcoin library code that end users or applications depend on, and no security vulnerability is introduced or fixed.

This change removes the ability to accidentally print a Bitcoin private key using Rust's standard '{}' formatting. Before, code like println!("{}", private_key) would expose the secret key. Now developers must explicitly call .to_wif() or similar methods, making secret leakage less likely through casual logging or error messages. It is a defensive hardening improvement, not a fix for an active exploit.

This commit removes the ability to use square-bracket slicing (like `private_key[..]`) on a Bitcoin private key. The change is part of a longer-term effort to prevent secret key material from being accidentally exposed through Rust's indexing features. It is a hardening cleanup rather than a fix for an active security flaw.

This commit adds a human-readable hex display format for Taproot signatures in the rust-bitcoin library, matching a similar feature already available for ECDSA signatures. It is a straightforward feature addition with tests and does not fix any security bug.

This commit adds a new feature: the ability to parse a Taproot cryptographic signature from a hexadecimal text string. Previously only ECDSA signatures could be parsed this way. The change is purely additive and does not fix any known bug or vulnerability. It simply exposes a new parsing function to users of the library.