rust-bitcoin

This commit is a simple rename of a method from 'extend' to 'join' in a Rust Bitcoin library. It does not change what the code does, only its name. There is no security issue here.

This commit refactors how Bitcoin BIP-32 derivation paths are represented in the rust-bitcoin library. It splits the old single DerivationPath type into two: DerivationPath (relative paths like 0'/1) and AbsoluteDerivationPath (master-prefixed paths like m/0'/1). The goal is to make wallet code more explicit about whether it is deriving from the master key or from an intermediate key. The change is a type-system/API hardening, not a fix for a known exploitable bug. It may prevent future misuse where a relative path is accidentally treated as absolute or vice versa, but the commit itself does not describe any active vulnerability.

This is a routine code cleanup that renames the type `DerivationPath` to `RelativeDerivationPath` throughout the project. The change is purely a refactor: it does not alter how the code behaves, what it computes, or how it handles data. The commit message explicitly says the rename is intended to force other developers to update their code so the maintainers can identify places that may later need a new `AbsoluteDerivationPath` type. There is no security fix or vulnerability here.

This is a small internal code cleanup in a Bitcoin library. It splits one function into two so the inner logic doesn't have to be repeated, but the public behavior is unchanged. There is no security issue visible in the change.

This is a minor code cleanup for an error type in the BIP-32 (Bitcoin key derivation) module. It adds a standard 'Copy' trait, a conversion from Rust's 'Infallible' type, an explicit 'no underlying cause' implementation, and slightly clarifies an error message. There is no security fix or behavior change.

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 fixes a low-level memory-safety issue in the SHA-256 code that runs on ARM 64-bit processors (aarch64). The code was asking the CPU to load four 32-bit numbers starting from a pointer that only pointed to a single 32-bit number. Rust's strict memory rules (flagged by the Miri checker) consider this undefined behavior, even though real hardware often tolerates it. The fix uses a pointer to the whole array instead, so the load is clearly valid.

This commit only reformats the wording and layout of multiple CHANGELOG.md files. It adds a top-level 'Changelog' heading, converts release headings from H1 to H2, adds an 'Unreleased' section, and appends Markdown link references that point to git tags or comparison URLs. No program code, build scripts, dependencies, or documentation that affects behavior were changed. There is no security relevance.

This commit only fixes broken or missing backticks in documentation comments within two example files. It changes how Rustdoc links and formats text, with no effect on actual program behavior or security.

This commit is purely a maintenance update to the project's continuous integration (CI) tooling. It upgrades an internal helper tool called cargo-rbmt and regenerates large API snapshot files because the new version produces cleaner, de-duplicated output. No actual Bitcoin library code was changed, and 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 is a straightforward code cleanup in the rust-bitcoin library. It removes top-level imports of serde serialization traits and replaces them with explicit `serde::` prefixes in the key module. There is no functional change to how keys are serialized or deserialized, and no security issue is introduced or fixed.

This commit is a straightforward internal code reorganization. It takes a single large module named 'encapsulate' in the cryptographic key code and splits it into several smaller modules, one for each key type. The public types and their behavior remain exactly the same; only the internal file/module structure and re-export paths changed. 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 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 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 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.