rust-bitcoin

This commit fixes a bug in how X-only public keys were created from full public keys. An X-only key is just the X coordinate of a point, but a point can have an even or odd Y coordinate (parity). The old code always assumed even parity, which could silently produce the wrong key for odd-parity inputs. The fix preserves the actual parity from the source key.

This commit is a routine internal code reorganization. It moves the PublicKey and PrivateKey type definitions into a private 'encapsulate' module and re-exports them publicly. The fields were already private before this change, so no new access restrictions are introduced. There is no indication this fixes a security bug or changes behavior visible to users of the library.

This commit hides the internal fields of two key types (PublicKey and PrivateKey) so outside code can no longer read or change them directly. Instead, it provides read-only accessor methods. This is a normal defensive-coding change that improves encapsulation and makes future misuse less likely, but the commit itself does not fix a known active bug or vulnerability.

This commit hides the internal cryptographic key fields of PublicKey and PrivateKey from outside code, replacing direct access with controlled getter methods. It is a defensive hardening change that reduces the chance future callers will accidentally misuse or mutate the raw secp256k1 keys, but the commit itself does not fix a known exploitable bug.

This is a routine code cleanup in the rust-bitcoin library. It introduces new constructor functions named from_secp for creating public and private keys, and replaces direct internal field access with calls to those constructors. The old constructors are kept but marked as deprecated. There is no security bug being fixed here; the change is about improving code structure and preparing to hide internal details in the future.

This commit adds a best-effort memory-clearing helper for two cryptographic building blocks (HMAC and HKDF) in the rust-bitcoin library. It tries to overwrite secret intermediate data with zeros when those objects are destroyed, but the authors explicitly note this is not a guaranteed security fix because the Rust compiler may still leave copies of the data elsewhere in memory. The change is defensive hardening rather than a fix for a known exploitable bug.

This commit is a routine build-maintenance change. It removes an old shell script used to update dependency lock files and switches the project to using a new internal tool called cargo-rbmt for the same task. There is no change to the actual Bitcoin library code, no security fix, and no vulnerability introduced.

This commit adds new encoding and decoding machinery for a Bitcoin compact-block-relay data structure called HeaderAndShortIds. It preserves an existing safety check that prevents the combined number of short transaction IDs and prefilled transactions from overflowing a 16-bit limit. The change is mostly a refactor to use newer generic encoder traits; it does not appear to introduce a new vulnerability, but the author notes they do not fully understand why the overflow check guarantees safety of individual index differences.

This is a routine code cleanup that makes the crate's no_std setup consistent with other crates in the same repository. It does not fix a security bug and does not change behavior for users.

This commit is a routine API cleanup in the rust-bitcoin library. It removes an extra 'parity' argument and return value from functions that tweak public keys for Taproot, because the parity information can now be stored directly inside the XOnlyPublicKey type. There is no indication this fixes a security bug; it is a design simplification that may require downstream code to update how it calls these functions.

This commit is a routine API cleanup, not a security fix. It renames a method from `public_key` to `to_public_key` and removes a now-redundant `parity` argument because the parity information is already stored inside the x-only public key object. The code still produces the same public keys; callers just provide the parity in a different way. There is no indication this change fixes a vulnerability.

This commit is a routine API cleanup in the rust-bitcoin library. It changes a function so it returns only the x-only public key, instead of a pair of the key plus its parity bit. The parity information is now stored inside the key object itself, so callers no longer need to handle it separately. There is no security vulnerability here.

This commit changes the public API of XOnlyPublicKey::serialize() so it now returns both the 32-byte x-only key and its parity bit, instead of just the bytes. All existing callers inside the crate are updated to take only the first element (the bytes) and ignore the parity where it isn't needed. This is a routine API design change to expose extra information for users who need to fully reconstruct a key; it does not fix a bug or close a security hole.

This is a routine internal code refactor in a Bitcoin cryptography library. It adds a 'parity' field (a mathematical property of cryptographic keys) to the XOnlyPublicKey type, along with getter and setter functions. There is no indication this change fixes or introduces a security vulnerability.

This commit changes how a Bitcoin public-key type is serialized and deserialized when the optional serde feature is enabled. The old code automatically used the inner key type's format, which would break if extra data (such as key parity) is added later. The new code explicitly forwards to the inner type, keeping the wire format stable even as the wrapper type evolves. It is a hardening/preventive change rather than a fix for an active vulnerability.

This commit simply renames a function from XOnlyPublicKey::new to XOnlyPublicKey::from_secp because the old name was misleading. The underlying behavior is unchanged. There is no security vulnerability or fix here.

This commit adds a small performance helper method called as_inner() to the XOnlyPublicKey type and switches existing internal code to use it instead of a method that copies the key. There is no security issue here; it is a routine optimization to avoid unnecessary copying.

This commit is a routine automated code-formatting run using the nightly version of rustfmt. It only changes whitespace, line breaks, import ordering, and other stylistic details across 24 files. No program logic, security behavior, or public API was changed.

This commit is a routine housekeeping change that moves lint (code style warning) settings from individual crates to a shared workspace configuration. It does not change any program logic, fix bugs, or alter security behavior.

This commit is a routine internal dependency cleanup. The project had been re-exporting an unstable version of a hex-encoding helper crate, but its policy says the main crate must only re-export stable versions. The change swaps the public re-export to the stable version while keeping the unstable version as a private internal dependency for code that still needs it. There is no security bug being fixed here.

This change lets users of the library who don't use the standard Rust library ('no_std' environments, common in embedded or blockchain hardware) benefit from faster SHA-256 hashing via CPU-specific instructions. It adds an optional helper crate that detects CPU features in 'no_std' mode, similar to how the standard library already does it. There is no direct evidence in the commit that this fixes a security vulnerability; it is a performance and portability improvement.

This commit only adds a new performance benchmark for the SHA256d hashing function. It does not change any production code, cryptographic logic, or user-facing behavior. There is no security issue.

This change only fixes how hash performance is measured in benchmark tests. It does not change any real hashing code that users or applications rely on, so it has no security impact on the library itself.

This commit fixes a bug in how Partially Signed Bitcoin Transactions (PSBTs) read and write their internal 'key' fields. The old code assumed the key's type number always fits in one byte when encoded as a compact size. That assumption is wrong for large type numbers, so the code could misread the key's length and either reject valid PSBTs or, in the worst case, allocate too much memory. The fix makes the encoder and decoder correctly account for the actual number of bytes the type number occupies.

This commit only adds a new test to verify that HMAC hashing still produces the correct result when data is fed in one byte at a time. It does not change any production code, fix a bug, or alter behavior. The existing code already handled incremental input correctly; the change simply adds missing test coverage.