rust-bitcoin

This commit is a straightforward API refactor in the BIP-32 (Bitcoin key derivation) code. It replaces a function that returned a raw secret key and chain code with one that returns a new structured type called XpubChildTweak. The actual cryptographic math and behavior remain the same; only the way callers receive the result has changed. There is no indication this fixes a security bug.

This is a routine code cleanup in a Bitcoin library. It renames key-derivation methods on extended public and private keys (Xpub/Xpriv) to clearer names and removes old aliases. There is no security bug being fixed and no new vulnerability introduced; it is purely a refactoring that may require downstream developers to update their code.

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

This commit adds standard Rust conversion traits (From/TryFrom) between an ECDSA signature and its serialized byte form. It is a small API-consistency change that mirrors traits already present on the Taproot signature type. There is no indication it fixes a security bug or introduces a vulnerability.

This commit adds new ways to print ECDSA Bitcoin signatures as hexadecimal text (lowercase and uppercase), matching formatting already available for Taproot signatures. It also makes the existing Display implementation reuse the new LowerHex implementation. There is no security fix or behavior change that affects signatures themselves—only how they look when formatted as text.

This commit fixes a formatting bug in how Bitcoin ECDSA signatures are printed as text. Previously, the signature was printed in two separate pieces (the DER-encoded signature and the sighash byte), which could mishandle formatting options like width or precision. Now it prints a single pre-serialized object, so formatting behaves consistently. This is a correctness bug, not a cryptographic vulnerability, and there is no evidence it enables code execution or theft of funds.

This commit simply adds standard sorting traits (PartialOrd and Ord) to an ECDSA signature type and its associated sighash type, matching what already exists for similar types. There is no indication this fixes or introduces a security problem.

This commit is a routine API cleanup, not a security fix. It removes a helper trait called PrivateKeyExt and hides a low-level accessor method (as_inner) that exposes the underlying secret key object. The same signing behavior is preserved inside the crate, just with less public surface area. There is no patch for an active vulnerability.

This commit is a code cleanup: it splits one big error type into several smaller, more specific error types for BIP-32 extended key parsing. It does not change what the code accepts or rejects, only how errors are named and organized. There is no security fix here.

This commit is a pure code-style change. It reorders the implementation blocks for several error types in a Bitcoin-related Rust library so that the order of traits (From, std::error::Error, Display, helper methods) is consistent. No logic, behavior, or security properties of the code are changed.

This commit removes old serialization/deserialization trait implementations (called Encodable and Decodable) from many Bitcoin data types in the rust-bitcoin library. It is described by the project as a cleanup step toward replacing the old consensus encoding code. There is no indication in the commit or supplied references that this fixes a security vulnerability; it appears to be a routine internal refactor.

This commit swaps out an older Bitcoin data-encoding system for a newer one across six files. It is a routine internal refactoring change. There is no direct evidence in the commit that it fixes a security vulnerability, but any encoding change in consensus-critical code carries a small risk that a subtle behavior difference could affect transaction or block validation. The commit message and diff do not describe any security issue or credit a researcher.

This commit only changes test code and documentation examples in the rust-bitcoin library. It replaces older consensus encoding/decoding helper functions with newer equivalents from a different internal module. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit adds a new convenience method, XOnlyPublicKey::verify, that lets users verify Schnorr (taproot) signatures without calling the underlying secp256k1 library directly. It is a straightforward API addition with no obvious security bug; it simply wraps the existing, well-tested secp256k1 Schnorr verification routine.

This commit is a code cleanup (refactor) that splits one combined error type into two separate error types for parsing BIP32 derivation paths. It does not change the actual parsing rules or fix any security bug. It only changes how error messages are categorized internally, making the API clearer for developers. There is no indication this addresses a vulnerability.

This commit is a code cleanup in the rust-bitcoin library. It splits one general BIP32 derivation error type into several more specific error types and renames the old one. It does not change how keys are actually derived or add any new security behavior; it only changes how error conditions are named and reported to programmers.

This commit only adds a new regression test. It does not change any production code. The test checks that a function called from_base64 correctly rejects base64 inputs that decode to fewer or more than 65 bytes. Because no actual fix is included in this commit, the commit itself does not introduce or remove a security vulnerability; it merely adds a test to help catch the bug in the future.

This commit fixes a denial-of-service (DoS) weakness in how the rust-bitcoin library decodes Bitcoin transaction witness data. Previously, an attacker could send only about 10 bytes of data and trick the decoder into reserving 16 MB of memory up front. The new code only allocates memory for bytes that have actually arrived, making memory-exhaustion attacks much harder. The commit also simplifies the code and removes several helper functions and constants.

This commit is a routine code cleanup: it moves a small test-only helper macro from a shared internal utility crate into the one place it is actually used. There is no change to user-facing behavior, no bug fix, and no security relevance.

This commit removes an unused error category from a Bitcoin cryptography library. It is a cleanup change because the underlying signature-parsing code can no longer fail in the way that error category described. There is no direct evidence this fixes an active security bug, but it does slightly reduce the library's public error surface, which can help downstream code handle errors more reliably.

This commit removes a convenience conversion that let users turn a borrowed Taproot signature into an owned, serialized byte form. The change is API-cleanup: the old trait made it look like the serialized form was just a view of the original signature, when it actually copies/owns the bytes. There is no direct security bug fixed here, but removing the misleading conversion reduces the chance that future callers misunderstand ownership and accidentally clone or mishandle signature data.

This commit is a code-quality maintenance change. It adds pattern-matching destructuring inside Rust error-type 'source' methods that previously just returned 'None'. The goal is to make the compiler warn future maintainers if the shape of an error type changes, so they remember to update the source() implementation. It does not change runtime behavior, fix a bug, or close a security vulnerability.

This commit adds two small Rust trait implementations that allow certain error types to be automatically converted from the 'Infallible' type. 'Infallible' is a type that can never actually exist, so these conversions are purely for making the error types easier to use in generic code. There is no security issue here.

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