rust-bitcoin

This commit simply moves existing transaction encoding and decoding tests from one file to another. It does not change any production code, only reorganizes test code. The only functional tweak is replacing one detailed error comparison with a broader pattern match, because the moved test can no longer see a private inner error type. There is no security issue here.

This commit is a large but straightforward internal code reorganization. It moves Bitcoin key types (public keys, private keys, keypairs, and related errors) from the main `bitcoin` crate into a new `crypto` sub-crate, then re-exports them so existing users of the `bitcoin` crate see the same public API. There is no indication of a security bug being fixed or introduced; it is a refactoring to improve the project's modular structure.

This commit is a routine version bump for an internal Rust crate. It changes the package version from 0.0.0 to 0.1.0, updates dependency references and lock files, and records the migration of code into the crate in the changelog. There are no code logic changes and no security-relevant behavior changes visible in the diff.

This commit is a routine internal code reorganization. It moves a low-level ECDSA signing helper method from the main PrivateKey implementation into a new extension trait called PrivateKeyExt, and updates the one place that uses it to import the trait. There is no change to what the code does or any security fix.

This is a small code-quality change in how a Bitcoin-related Rust library reports parsing errors for a special sighash type. It makes the error message come directly from the underlying Taproot parser instead of being manually rebuilt. There is no direct security vulnerability here, but it slightly improves error-message accuracy and removes a tiny bit of duplicated logic.

This commit only cleans up style warnings in a Rust source file. It replaces wildcard imports with explicit Self:: references, adds a documentation comment, and fixes a minor formatting issue in a doc comment. There is no change to program behavior or security.

This commit is a routine code reorganization: it moves some Bitcoin signature-hash type definitions (EcdsaSighashType, TapSighashType, and related error types) from the main bitcoin crate into a new bitcoin-crypto sub-crate, then re-exports them so existing users see no change. There is no functional change to how signatures or transactions are validated.

This commit is a simple internal code cleanup in the rust-bitcoin library. It moves two nearly identical helper functions into a shared internal trait, without changing what the code does or how it behaves. There is no security issue here.

This commit is a routine code cleanup in the rust-bitcoin crypto crate. It fixes compiler lint warnings by adding documentation comments, adjusting number formatting, and making minor style changes. There is no functional change to how signatures are created, validated, or parsed, and no security issue is present.

This commit is a routine internal code reorganization. It moves the ECDSA signature module from the main 'bitcoin' crate into a smaller 'crypto' sub-crate, then re-exports it so existing users see no change. There is no security fix or vulnerability here.

This commit is a routine internal code reorganization. It moves a few public-key helper methods into Rust 'extension traits' so the underlying key types can be relocated to a different crate later. The actual behavior of the moved functions is unchanged, and there is no indication of a bug fix or security patch.

This commit is a routine fix to the project's automated fuzz-testing pipeline. It adds an installation step for the 'cargo-fuzz' tool in one CI job and updates a script that generates the workflow file. There is no change to the actual Bitcoin library code that users depend on, and nothing in the commit suggests a security vulnerability or fix.

This is a routine code cleanup in an example file. It replaces an old, deprecated method name (`public_key`) with the newer recommended name (`to_public_key`). There is no security issue here; the change only affects example documentation code and does not alter how the library works.

This commit changes how test-only fake data is generated for an extended Bitcoin private key (Xpriv) when the optional 'arbitrary' feature is enabled. Previously, the generator always produced a 'master' key with depth 0. Now it can produce keys at any depth with proper parent fingerprint and child number fields. This is a code-quality/test-coverage improvement; it does not change production key handling or add a security vulnerability.

This commit is a routine internal cleanup in the rust-bitcoin library's data-encoding machinery. It removes unnecessary 'Option' wrappers from several encoder types and stops guaranteeing that encoders return an empty slice after they are exhausted. Instead, calling 'current_chunk()' on an exhausted encoder may now panic in some composite cases. The change is framed by the author as a performance and code-simplification improvement, not as a security fix. There is no evidence in the commit or supplied references of an exploitable vulnerability.

This commit adds a new example program to the rust-bitcoin library's p2p crate. It demonstrates how to perform a Bitcoin peer-to-peer handshake and respond to ping messages with pong messages. It is documentation/example code only and does not change any library behavior or fix any security issue.

This commit is purely a code-formatting cleanup. It only changes whitespace, import order, line breaks, and trailing blank lines. There are no functional changes, no bug fixes, and no security-related modifications.

This commit adds a new helper type for storing Bitcoin legacy public keys in their serialized form without needing a heap allocation. It is a routine internal API improvement and does not fix any security bug or change how keys are validated.

This commit only updates a generated text file listing the public API surface of the crate. It records that a new error type, FromHexError, is now part of the public API. There is no code change, no bug fix, and no security relevance visible in the diff.

This commit only updates generated API snapshot text files to reflect that two existing types (Target and Work) now also implement Binary and Octal formatting traits in addition to the formatting traits they already supported. There is no code change, no bug fix, and no security relevance visible in the diff.

This commit adds a performance optimization for computing SHA-256 hashes on modern x86 processors that support Intel's SHA-NI instructions. It is a routine feature addition, not a security fix or vulnerability patch. There is no indication in the commit that it addresses a security issue.

This commit is a performance optimization for Bitcoin's double-SHA256 hashing on modern Intel/AMD processors. It rewrites a low-level routine to compute two independent hashes at once instead of one, filling idle CPU cycles. There is no security fix or vulnerability here; it is purely about making hashing faster.

This commit adds a new, highly optimized x86 implementation for computing a double SHA-256 hash (SHA256d) on exactly 64 bytes of input. It uses Intel SHA-NI CPU instructions and precomputed constants to speed up Bitcoin-style hashing. There is no indication in the commit that this fixes a security bug; it appears to be a pure performance optimization.

This commit only changes comments in the SHA-256 code. It makes the round-number labels consistent between different versions of the optimized code (ARM and x86). No actual program logic, math, or behavior was changed, so it cannot affect security or correctness.

This commit is a pure file reorganization: it splits the SHA-256 cryptographic implementation from one large file into several smaller files. The author explicitly states there is no logic change, and the diff shows the same code being moved into new modules with only minor module wiring adjustments. There is no security-relevant change visible.