rust-bitcoin

This commit simply moves an existing implementation of the Drop trait for the Keypair type to a different location in the same source file. It does not change what the code does, only where it appears in the file. There is no security impact.

This commit is a pure code cleanup: it reorders where certain trait implementations (like FromStr, From, Display, Debug) appear in the source file so all types follow the same consistent pattern. No code behavior is changed, no security bug is fixed, and no vulnerability is introduced.

This commit is a pure code reorganization: it moves existing Rust 'From' conversion implementations so they sit directly underneath the type they produce, rather than being scattered near the source type. No logic, behavior, or public API changes are visible in the diff.

This is a small internal code cleanup in the rust-bitcoin library. It replaces a slightly longer implementation of converting one public key type to another with a shorter one that calls an existing conversion. There is no change in behavior and no security issue.

This commit simply updates a dependency version number used only in fuzz testing infrastructure. It changes the pinned version of an older 'bitcoin' crate from 0.32.8 to 0.32.9 in lock files and fuzz configuration files. There is no indication this is a security fix for the main project, nor does the commit itself describe any security relevance.

This commit fixes how the rust-bitcoin library handles malformed 'fee filter' messages from the Bitcoin peer-to-peer network. Previously, out-of-range fee values were silently clamped to the maximum allowed rate, which could make messages fail to 'round-trip' (encode back to the same bytes) and could subtly corrupt checksum calculations. Now those invalid values cause a clear decoding error instead, matching the behavior of Bitcoin Core.

This commit only changes a fuzz testing target. It tells the fuzzer to ignore certain known, expected differences between old and new Bitcoin encoding/decoding code. It does not change the actual library code that handles transactions, addresses, or network messages, so it cannot directly affect real users or introduce a security vulnerability.

This commit fixes a regression in the Bitcoin peer-to-peer address decoder. A recent rewrite accidentally stopped rejecting oversized network addresses (over 512 bytes), which could let malformed or unusually large data pass through as an unknown address type. The patch restores the original safety check that rejects such oversized inputs with an explicit error.

This is a tiny build-configuration cleanup. It removes a non-existent feature flag ('hashes/arbitrary') from a list of features that get enabled when the 'arbitrary' feature is turned on in the taproot-primitives crate. The flag pointed to a feature that does not exist in the hashes crate, so it had no effect and could not cause a security problem. The change simply prevents a harmless misconfiguration.

This is a one-line fix to a code example so it uses a configurable network parameter instead of always using the regtest network. It is not a security fix and does not change any library behavior.

This change improves error messages when decoding Bitcoin peer-to-peer network messages. Previously, if the message header failed to decode, the higher-level decoder would report a generic 'header error' with no details. Now it wraps and preserves the underlying header decoder error so callers can see what specifically went wrong. There is no security vulnerability being fixed here; it is a usability and diagnostics improvement.

This is a small internal code cleanup in the Bitcoin peer-to-peer message decoder. It replaces a hand-built four-part header decoder with an existing dedicated header decoder. There is no security bug being fixed; the change is purely for code reuse and slightly better error messages.

This commit is a small internal code cleanup in the Bitcoin peer-to-peer message decoder. It changes how message length and network magic bytes are stored while being parsed, switching from raw byte arrays to already-parsed types. There is no security fix here; it is purely a refactoring to simplify the code and make future maintenance easier.

This commit only changes a fuzz testing target so it ignores additional known differences between old and new Bitcoin data decoders. It is a test-configuration update, not a fix to production code, and does not change how real transactions are validated.

This commit adds a single formatting directive (`#[rustfmt::skip]`) to tell Rust's automatic code formatter not to reformat a specific SHA-256 hashing function. It does not change any executable code, logic, or behavior. There is no security impact.

This is a small performance improvement in the rust-bitcoin library's SHA256 double-hash code. It replaces a slower fallback code path with a faster, already-existing internal implementation when advanced CPU features are not available. There is no indication of a security bug or vulnerability.

This commit adds a new, highly optimized software-only implementation for computing a double SHA-256 hash on exactly 64 bytes of data. It is intended as a fallback for older CPUs that lack hardware-accelerated hashing instructions. There is no indication in the commit that this fixes a security bug; it appears to be a performance or portability improvement.

This commit is purely a code-formatting cleanup. It runs rustfmt across several files, which only changes whitespace, line breaks, and the order of import statements. No program logic, security checks, or behavior were changed.

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 adds a small convenience method called `with_compressedness` to a public-key type in the rust-bitcoin library. It lets callers flip whether a Bitcoin public key is stored in compressed or uncompressed form without having to reach into lower-level secp256k1 cryptography types. The change is purely an API usability improvement and does not fix any bug or vulnerability.

This commit is a routine internal cleanup in the rust-bitcoin crypto library. It removes an older helper method named with_serialized from LegacyPublicKey and replaces its uses with a newer, simpler method called to_bytes. There is no indication of a bug fix or security patch in the change itself or the commit message.

This commit only fixes code style and documentation lint warnings in the crypto::taproot module. It adds missing documentation comments and formats an existing doc comment. There are no changes to program logic, security behavior, or cryptographic operations.

This commit is a routine code reorganization. It moves two existing error types (SigFromSliceError and ParseSignatureError) into a new 'error' submodule within the taproot module and re-exports them publicly. There is no change to how signatures are validated, parsed, or what errors are returned. It is purely a structural cleanup to match the project's coding patterns.

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.