rust-bitcoin

This commit adds two new helper methods, serialize_compressed and serialize_uncompressed, to the bitcoin::PublicKey type. Previously, users had to reach into the underlying secp256k1 library to serialize a public key. The change simply wraps that existing behavior in a more convenient API and updates internal callers to use the new methods. There is no indication of a security bug being fixed.

This commit adds a new helper method, to_secret_bytes, to the PrivateKey type in the rust-bitcoin library. It returns a private key as a fixed 32-byte array instead of a variable-length vector. The existing to_secret_vec method is rewritten to use the new helper. There is no visible security fix or behavior change; it is a routine API convenience addition.

This commit simply changes an existing internal helper function to be publicly usable and adds documentation and examples. It does not fix a bug, change behavior, or introduce any new security-sensitive logic. The function already existed and behaved the same way; only its visibility changed from private to public.

This commit only adds new automated tests that check whether Bitcoin-style cryptographic keys can be converted to and from the underlying secp256k1 library's key types. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit simply deletes a stale README file inside the GitHub workflows folder. It contains only documentation about CI job names and GitHub Actions usage limits. No code, configuration, or security controls were changed.

This commit adds a new performance-oriented function for computing many double-SHA256 hashes at once, with a special two-at-a-time path for ARM CPUs that support SHA2 hardware instructions. It also exposes that function as a new public API. There is nothing in the diff that fixes a bug, checks bounds incorrectly, or introduces an obvious security flaw; it appears to be a routine optimization and API addition.

This commit is a performance optimization for SHA256 double hashing on 64-bit ARM processors. It rewrites a single-hash ARM hardware-accelerated routine to compute two independent hashes at the same time, filling otherwise wasted CPU cycles. There is no security bug being fixed and no new attack surface introduced; it is purely a speed improvement.

This commit adds a new, highly optimized way to compute a double SHA-256 hash on 64-byte inputs for 64-bit ARM processors (aarch64) using special CPU instructions. It is a pure performance improvement and does not change any public APIs or fix any known bug. There is no indication in the commit that it addresses a security vulnerability.

This commit only adds new unit tests for serializing and deserializing Bitcoin peer-to-peer address messages. It does not change any production code, fix a bug, or alter behavior. There is no security relevance.

This commit adds standard encoding and decoding support for a new P2P network message container (AddrV2Payload). It is a routine, vector-counterpart follow-up to a previous commit and does not appear to fix or introduce any security issue on its own.

This commit adds encoding and decoding support for a Bitcoin peer-to-peer network address message type (AddrV2Message). It changes how the 'services' field is decoded so it can accept very large numbers sent by some real Bitcoin nodes, instead of being limited to 32-bit values. The commit message says this is safe because the value is not used to allocate memory. There is no direct evidence in the commit that this fixes a security vulnerability, but handling unexpectedly large input values is a common place where bugs can occur.

This commit is a routine API cleanup: it renames a method on the PrivateKey type from public_key to to_public_key and keeps the old name as a deprecated alias. It does not change what the code does, only how callers spell the function name. There is no security bug being fixed.

This commit fixes a behavioral mismatch in a new Bitcoin data-decoding library. Previously, the new decoder would silently accept an empty byte slice as an empty list, while the older code rejected it because it lacked a length prefix. The change makes the new decoder reject empty inputs too, preventing subtle parsing differences that could affect how transactions or network messages are interpreted across versions.

This commit only updates generated API snapshot files that list what public types and functions exist in the rust-bitcoin 'primitives' crate. No actual source code was changed, and nothing in the commit message or diff suggests a security fix or vulnerability. It is a routine housekeeping change.

This commit only adds new test code to check that certain 'decoder' types can be created with a default value and a `new()` function. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit adds convenient ways to create certain Bitcoin data decoders (Default and new()) in the rust-bitcoin library. It does not change how data is parsed or validated, and there is no indication it fixes or introduces a security problem.

This commit is a purely cosmetic refactor of how hash types are declared in the rust-bitcoin library. It changes the internal macro syntax from a custom list of numbers and flags to something that looks more like ordinary Rust code. There is no change to the actual hashing behavior, output, or public API.

This is a routine automated code-formatting commit. It only changes whitespace, import order, line wrapping, and other stylistic details produced by the rustfmt tool. There are no functional changes, bug fixes, or security-related modifications.

This is a routine internal code cleanup in the rust-bitcoin peer-to-peer networking module. It swaps a general-purpose macro for a more specific one when building message encoders, because the newer macro can do everything the old one does and more. There is no user-facing behavior change and no security fix.

This is a routine library improvement that lets users ask 'how many bytes will this transaction input/output take up when encoded?' without actually encoding it. It adds a length method to two encoder types by switching to a macro that supports exact-size encoders. There is no security bug being fixed and no indication this change addresses any vulnerability.

This commit simply updates the version of the Rust nightly compiler used by the project's automated GitHub CI tests from one weekly nightly build to the next. It changes only a single version string in a configuration file. There is no code change, no bug fix, and no security-relevant behavior change.

This commit simply bumps the version number of a CI linting tool (cargo-semver-checks) used in GitHub Actions from 0.46.0 to 0.47.0. It changes one line in a workflow configuration file and has no effect on the actual Bitcoin library code, runtime behavior, or security.

This commit is a routine cleanup of how optional dependencies are declared in three Rust package configuration files. It changes feature flags to use the modern `dep:` syntax and updates comments to be clearer. There is no change to actual program logic, no security fix, and no vulnerability.

This commit simply updates a single version number in a CI configuration file from Rust compiler version 1.93.1 to 1.94.0. It changes no application code, no cryptographic logic, and no user-facing behavior. There is no security relevance.

This commit only updates a generated text file that lists the public API surface of the crate. No actual source code, logic, or behavior changed. It is a documentation/tracking update, not a security fix or functional change.