rust-bitcoin

This commit is a routine API ergonomics improvement. It changes two Rust macros so that the caller can specify the visibility of the generated struct and its constructor (e.g., public, private, or crate-visible), instead of always forcing public visibility. The change is explicitly described as backwards compatible and follows a documented Rust API convention.

This commit adds a new helper function that lets developers flush an existing data encoder directly to an output writer. It is a straightforward code refactor that splits an existing function into two pieces; there is no indication of a security bug or fix.

This commit fixes a bug where the Rust Bitcoin library incorrectly accepted 65-byte Taproot signatures whose final byte was 0x00. Under Bitcoin's BIP-341 rules, such signatures are invalid. Accepting them could let invalid transactions or signatures slip through, and it could break the library's own round-trip serialization (reading a signature in and writing it back out).

This commit adds Rust's #[track_caller] attribute to two methods in a decoding trait. This is a diagnostic improvement: if the code ever panics, the error message will point to the caller's location instead of deep inside the library. It does not change what the code does, what data it accepts, or whether it panics. There is no security fix here.

This commit is a routine release-management change for the rust-bitcoin project. It re-releases several crates without the '-rc' (release candidate) suffix in their version numbers and updates internal dependency version requirements accordingly. There are no code logic changes, bug fixes, or security patches in the diff—only version numbers, lock files, changelogs, and README text.

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 is a one-word documentation fix. A comment that referenced another type was changed from plain text to a proper Rust doc link so that documentation tools can create a clickable link. There is no code behavior change and no security relevance.

This commit only adds two standard metadata fields (homepage and documentation URLs) to a Rust package manifest file. It does not change any executable code, cryptographic logic, or network behavior. There is no security relevance.

This commit updates a generated API snapshot file to reflect a minor relaxation of trait bounds on an error type. It is a documentation/tracking file change, not a code change, and has no security relevance.

This is a minor code cleanup in a Rust Bitcoin library. It removes unnecessary requirements (trait bounds) from an error-handling implementation. The change does not affect security, runtime behavior, or how the library processes Bitcoin data.

This commit fixes a bug in how custom or unknown Bitcoin peer-to-peer messages were being serialized. Previously, the code accidentally added an extra length number to the front of the raw payload bytes, so if you decoded an unknown message and re-encoded it, the bytes would not match. The fix writes the raw payload bytes directly without the extra length prefix, and adds a test to confirm round-trip encoding works.

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 only changes a CI configuration file to add the 'hex' feature to automated testing matrices. It does not modify any runtime code, APIs, or dependencies that could affect security. There is no security issue or fix here.

This commit only updates generated API snapshot files (text listings of public types and methods). It does not change any source code, behavior, or fix any bug. The added lines reflect new methods like non_secure_erase and Drop that already exist in the actual library code; the removed line shows Hkdf no longer implements Copy. These are documentation/snapshot updates, not a security patch.

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 only changes a test configuration file (rbmt.toml) to include an optional 'encoding' feature in the automated feature-flag testing matrix. It does not modify any production code, APIs, or security-sensitive logic. There is no security issue here.

This commit only adds Rust compiler hints (`#[inline]`) to a few small functions related to encoding and decoding block hashes. It does not change what the code does, only gives the compiler permission to embed these tiny functions directly at call sites for potential performance gains. There is no security relevance.

This commit simply reorders two blocks of code in a single Rust source file. It moves the implementation of the Decodable trait for BlockHash to appear earlier in the file, before the definition of its helper decoder type. The commit message and the diff confirm there is no change to program logic, behavior, or security.

This is a trivial code-style change. A developer replaced a direct import of the Encodable trait with its full path (encoding::Encodable) to make it clearer that the trait comes from another crate. No behavior, logic, or security properties changed.

This commit fixes a typo in an error message. The error message for a block hash decoding failure incorrectly said 'sequence decoder error' instead of 'block hash decoder error'. It is a cosmetic string correction with no security or functional impact.

This commit adds a new way to serialize (convert to bytes) Bitcoin peer-to-peer network addresses in the rust-bitcoin library. It does not appear to fix or introduce a security vulnerability; it is a routine implementation change replacing one serialization method with another while preserving the documented big-endian byte order.

This commit adds a new automated test that checks an Address object can be encoded to bytes and then decoded back to the same object. It does not change any production code, fix any bug, or alter behavior visible to users.