rust-bitcoin

This commit tightens input checking for Bitcoin wallet master-key creation. Previously, the library would accept any seed length when creating a BIP-32 master key, even though the standard only allows seeds between 16 and 64 bytes. Now it validates the length and rejects out-of-range seeds. It also changes how seed bytes are printed in debug logs so the full secret is no longer exposed, and compares seeds in constant time to reduce timing side-channel risk.

This commit fixes a safety check in the HMAC code. Previously, the code only verified in debug builds that a hash engine's block size did not exceed 128 bytes. In release builds, an oversized block size would cause the code to write past the end of fixed 128-byte internal buffers, leading to incorrect HMAC results or memory corruption. The fix makes this check run unconditionally by changing a debug-only assertion into a regular assertion.

This commit adds convenience helper methods that let developers sign Bitcoin transaction hash values more directly. It does not change any security-critical behavior; the same cryptographic signing operations were already available through other functions. The change is purely an API usability improvement.

This is a small API ergonomics change in a Rust Bitcoin library. A function called tap_tweak is changed so callers pass a reference to the key instead of giving up ownership of the key. It does not fix a bug or vulnerability; it makes the library easier to use in code that holds key references.

This commit is a routine release-preparation change. It bumps the version number of the `bitcoin_hashes` crate from 0.20.0 to 0.21.0, updates the project's lock files, and adds a changelog entry summarizing prior changes. There is no code change that fixes or introduces a security issue in this commit itself.

This is a purely cosmetic code-formatting commit. It only reorders imports, rewraps long lines, and collapses or expands function bodies to match the latest rustfmt nightly style. No program logic, behavior, or security properties were changed.

This is a routine code cleanup in the rust-bitcoin hashes library. It removes duplicate ways of asking a hash engine for the output length and byte type, directing callers to use the associated Hash type instead. The commit message explicitly says this fixes an inconsistency discovered for the sha512_256 output size, but the change itself is an API simplification, not a security patch. There is no evidence of a vulnerability being fixed.

This commit is a routine code reorganization. It moves a small helper macro that implements conversions for script push bytes from one internal file to a shared include directory, then pulls it back in with no functional changes. There is no security issue here.

This commit is a routine internal code reorganization. It moves the PushBytes family of types and helpers from the main bitcoin crate into a lower-level primitives crate, and adjusts re-exports and trait implementations accordingly. There is no indication of a security bug being fixed or introduced.

This is a routine code cleanup commit that fixes compiler lint warnings. It removes an unused import, simplifies how a borrowed reference is obtained, makes a large numeric constant more readable with underscores, and adds a missing semicolon. None of these changes affect program behavior or fix any security issue.

This commit only changes build configuration files (Cargo.toml and lock files) to add a new internal crate dependency. It does not modify any executable code, fix a bug, or address a security issue. It is a routine refactoring step to resolve a dependency direction problem during library development.

This commit refactors how BIP-32 child key indexes are represented in the rust-bitcoin library. Previously, the index was a public enum with separate fields for normal and hardened variants, and the commit message notes a FIXME: because those fields were public, callers could directly create an out-of-range index (for example, a 'normal' index with the high bit set). The change turns the type into a private newtype around a raw u32 and forces construction through checked constructors that validate the range. It is a defensive hardening change that closes a potential invariant violation, but it does not by itself fix a demonstrated exploit.

This commit is a routine automated code-formatting run by the rustfmt tool. It only changes whitespace, import order, and brace style in five files. There are no functional code changes, no bug fixes, and no security-related alterations.

This change is a routine code cleanup, not a security fix. It removes an overly broad feature gate so that parts of the Taproot cryptographic module are available even when the optional 'alloc' feature is disabled, while keeping functions that actually need memory allocation behind the gate. There is no indication it fixes a vulnerability.

This commit is a small internal cleanup in the rust-bitcoin library. It changes how a Taproot signature is parsed from a hexadecimal string so that it no longer needs to allocate a temporary byte vector. The change removes an unnecessary memory allocation but does not alter the allowed signature formats or fix any vulnerability. It is a performance and dependency-reduction refactor, not a security fix.

This commit is a routine dependency cleanup. The project previously had to use two different versions of the same hex-encoding helper library (one stable, one unstable preview) because a needed feature was only available in the unstable version. Now that the stable library released version 1.1.0 with that feature, the commit removes the unstable dependency and switches everything to the single stable version. It is not a security fix and does not change how the software behaves to users.

This commit adds a standard trait implementation that lets the Hmac type be used with property-testing tools. It is a routine feature addition, not a security fix or vulnerability.

This commit is a routine API cleanup in the rust-bitcoin crypto library. It removes a method called as_inner that returned a reference to the underlying key data, and replaces internal uses with to_inner, which returns the key by value. The underlying key type is small and cheap to copy, so this is a consistency improvement, not a security fix. There is no indication this change addresses a vulnerability.

This commit narrows the visibility of internal helper methods named to_inner on Bitcoin public-key types. Previously any outside code could call these methods to extract the raw underlying secp256k1 key objects; now only code inside the same module can do so. This is a defensive encapsulation change that reduces the public API surface and makes future misuse or accidental exposure of internal cryptographic details less likely. It is not a fix for an active vulnerability.

This commit only changes the capitalization of hash algorithm names in comments and documentation strings (for example, 'sha256' becomes 'SHA256' and 'sha256d' becomes 'SHA256d'). No program logic, code behavior, or security properties were modified.

This commit only fixes typos and formatting in documentation comments and test file comments. No code behavior changes.

This commit is a routine code reorganization. It moves one function, `from_key_and_merkle_root`, out of a low-level crate (`taproot-primitives`) and into a higher-level crate (`bitcoin`) as an 'extension trait.' The goal is to remove an internal dependency so the low-level crate can stabilize sooner. The actual computation performed by the function is unchanged.

This commit only fixes code style and documentation warnings (lint errors) in the key-expression crate. It adds missing documentation comments, marks some functions with #[must_use], rewrites number literals with underscores, and makes minor test helper signature changes. There is no change to runtime behavior or security logic.

This is a minor internal code cleanup in a Rust formatting helper. It changes one function from borrowing a small value to copying it, following a common Rust style suggestion. There is no security relevance.