rust-bitcoin

This commit adds a standard Rust equality trait (Eq) to the Bip32Seed type. It is a routine, non-functional change that does not alter behavior, fix a bug, or address any security issue. There is no security relevance.

This commit is a routine API cleanup in the rust-bitcoin library. It renames a public key serialization method from `to_bytes` to `serialize`, restores `to_bytes` as a deprecated alias that returns a plain byte vector, and updates internal callers to use the new name. There is no security fix or vulnerability here.

This commit only fixes the formatting of a documentation link. It changes 'BIP-340' to 'BIP-0340' and wraps the URL in angle brackets so it renders correctly in Rust's generated documentation. No code behavior was changed, and there is no security impact.

This commit is a simple variable rename from 'pk' to 'key' in two Rust functions because 'pk' is commonly understood to mean public key, while the parameter is actually a private key. There is no change to program logic, no security fix, and no behavior change.

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 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 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 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 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 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 commit is a routine code reorganization: it moves the BIP-32 (hierarchical deterministic wallet key) module from the main `bitcoin` crate into a new lower-level `key-expression` crate, then re-exports it so existing users of `bitcoin::bip32` see no change. There is no evidence in the commit of any security bug, vulnerability fix, or behavior change.

This commit is an automated code-formatting run by the rustfmt tool. It only adjusts whitespace and line breaks in four source files, making no changes to program logic, algorithms, or data handling. There is no security relevance.

This is a small code cleanup in how Taproot signatures are printed or formatted as text/hex. It removes a tiny bit of duplicated logic by reusing an existing serialization helper and adds two new formatting traits (LowerHex and UpperHex). There is no security issue visible in the change.

This commit only adds a new unit test for a bug fix that was already applied in the previous commit. It does not change any production code itself. The test verifies that a Taproot signature can be serialized back to the same hex string it was parsed from. Because the actual fix happened earlier, this commit alone does not introduce, fix, or worsen any security issue.

This commit fixes a crash when printing or formatting a Taproot serialized signature. The old code assumed every signature was the maximum possible length, but real signatures can be shorter. When a shorter signature was formatted, the code could panic or crash. The fix checks the actual length and formats with the correct size.

This commit is a routine code cleanup. It removes unnecessary '?' operators in functions that already return a Result. The behavior of the code is unchanged; it just makes the code slightly cleaner and avoids a clippy lint warning.

This commit fixes a timing attack weakness in the ChaCha20-Poly1305 decryption code. Previously, the code compared the authentication tag using Rust's normal `==` operator, which can stop early when it finds a mismatch. That early-stop behavior can leak information about how much of the tag is correct if an attacker can measure tiny timing differences. The patch replaces it with a constant-time comparison that always scans all 16 bytes, so no timing information about the tag's contents is revealed.

This commit is a routine code reorganization: it moves the Taproot signature types from the main `bitcoin` crate into a separate `crypto` crate and re-exports them so existing users keep working. There is no security fix or behavior change visible in the diff.

This commit removes two helper methods that wrote Taproot signatures to an output stream. It is a routine internal API cleanup to eliminate an unnecessary dependency on the `io` crate inside the crypto taproot module. There is no security vulnerability here; the change simply mirrors a prior cleanup done for ECDSA signature types.

This commit only adds new fuzz testing targets and updates build/CI configuration to run them. It does not change any production library code, so it cannot introduce a runtime security vulnerability in the released crate. It is a testing infrastructure change.

This commit is a small internal cleanup in the rust-bitcoin library. It changes how an error message stores the unrecognized text a user typed, switching from a standard String to a special no-allocation string wrapper called InputString. The visible effect is only a slight rewording of the error message shown when someone types an invalid sighash type. There is no security vulnerability being fixed here.

This commit simply moves existing unit tests from one place in the codebase to another. It does not change any production code, behavior, or fix any bug. There is no security impact.

This commit adds the ability to serialize and deserialize a small fixed-capacity vector type (ArrayVec) used inside the rust-bitcoin library. It is a routine feature addition with explicit guards against overflowing the capacity during deserialization. There is no indication this fixes a security bug or introduces a vulnerability.

This commit removes two PSBT (Partially Signed Bitcoin Transaction) fuzz testing targets from the project's automated fuzzing setup and adds a clarifying comment about why an explicit version number is needed for a local dependency. There is no change to the actual Bitcoin library code that users rely on, and nothing in the commit suggests a security vulnerability was fixed or introduced.