rust-bitcoin

This commit adds a new helper module that lets Rust Bitcoin types be serialized and deserialized using Bitcoin's standard binary encoding, exposed through the popular serde serialization framework. It is a feature/refactoring change: it introduces a cleaner way to get the same behavior that previously required more verbose code. There is no indication in the commit that it fixes a security bug or vulnerability.

This commit is a routine API refactor in the rust-bitcoin library. It splits the old PrivateKey type into two parts: a simpler PrivateKey that only stores the secret key and compression flag, and a new WifKey type that pairs a PrivateKey with a Bitcoin network for WIF import/export. The change removes the network field from PrivateKey and moves WIF-specific parsing, serialization, and formatting onto WifKey. There is no security fix here; it is a design cleanup to make the key types more general-purpose.

This commit removes a line from a code example that printed a randomly-generated private key. The example now only prints the Bitcoin address. It is a documentation/example cleanup, not a fix for a software vulnerability in the library itself.

This change makes two helper libraries (serde and arbitrary) publicly visible from several rust-bitcoin crates. It is a dependency-management convenience for downstream developers and does not fix or introduce any security vulnerability.

This is a routine performance cleanup, not a security fix. It removes an unnecessary intermediate memory allocation when converting a Bitcoin script to a hex string by using an iterator directly. There is no change to behavior, parsing, validation, or cryptographic handling.

This change relaxes a Rust type-system restriction so a particular byte-iterator helper can work with trait objects and slices, not just fixed-size types. It is a routine API ergonomics improvement with no security relevance visible in the commit.

This commit only changes test code. It adds a configuration gate so that certain cryptography specification tests are skipped when the code is built with a special fuzzing flag. The fuzzing flag intentionally disables encryption to make fuzz testing easier, which naturally causes those spec-compliance tests to fail. There is no change to production code and no security vulnerability is being fixed.

This commit only updates generated API snapshot files (text listings of public types and functions) to reflect a new CompactSizeU64Decoder type and a moved CompactSizeEncoder module path. No actual source code, logic, or behavior changes are present in the diff, so it has no security relevance on its own.

This commit is a pure code reorganization: it moves the compact-size integer encoder and decoder into a new dedicated file/module. The public API is unchanged, the logic is unchanged, and no security-relevant behavior is modified.

This commit adds a new way to create a compact-size encoder using a u64 value, and slightly tightens the existing usize constructor. It is a routine API improvement, not a security fix. There is no evidence in the commit or supplied references that this resolves any vulnerability.

This commit only adds new test code for the CompactSize encoding/decoding logic. It does not change any production code, so it cannot introduce a security vulnerability on its own. The tests verify that valid compact-size values encode and decode correctly, and that non-minimal encodings are rejected as errors.

This commit adds a new decoder for reading very large Bitcoin-style numbers (up to 64 bits) and refactors the existing length decoder to share the same parsing logic. The change itself is defensive: it separates 'length' decoding (which has a safety cap to prevent memory exhaustion) from 'raw number' decoding (which has no cap because it's not used for allocation). The commit does not fix a known exploit, but it strengthens the library's design so future callers are less likely to accidentally use an uncapped decoder for lengths.

This commit is a simple code cleanup: it replaces hardcoded numbers (0xFD, 0xFE, 0xFF) with named constants (PREFIX_U16, PREFIX_U32, PREFIX_U64) in the compact-size integer encoder/decoder. The behavior of the code is unchanged. There is no security fix or vulnerability here.

This commit adds the missing ability to encode (serialize) Bitcoin P2P v1 message headers, matching the existing decoding support. It is a straightforward feature addition with no security-relevant behavior change.

This commit adds optional support for the `arbitrary` crate, a Rust fuzz-testing helper, across several data types in the rust-bitcoin library. It does not change normal runtime behavior; the new code is only compiled when the optional `arbitrary` feature is enabled. There is no direct security vulnerability in the diff, but it slightly expands the library's dependency tree and public API surface for users who opt into the feature.

This commit only adds a new unit test; it does not change production code. The test checks that parsing a malformed PSBT key with an impossibly small byte-size field returns a proper error instead of crashing. The underlying panic/underflow bug was already fixed in an earlier change, so this patch is a regression test rather than a fix.

This commit only adds a new test file that checks how integer wrapper types parse hexadecimal strings. It does not change any production code, so it cannot introduce a security vulnerability on its own. It is a routine quality-assurance addition.

This commit only updates automatically-generated API listing files (text files that record what functions exist in the public interface). No actual source code was changed, and nothing was fixed or removed. It is purely a documentation/tracking update for newly added public functions introduced by earlier commits.

This commit changes how two Bitcoin locktime types (block height and median-time-past) parse hexadecimal strings. Previously, a single function accepted hex with or without a '0x' prefix. Now there are two separate functions: one that requires the '0x' prefix and one that rejects it. This is an API-consistency cleanup, not a fix for an exploitable vulnerability. Existing callers that relied on the old flexible behavior could break at compile time or runtime if they still pass unprefixed hex to from_hex, but the change is intentional and documented.

This commit adds new public helper functions that let several numeric wrapper types in the rust-bitcoin 'units' crate be created from hexadecimal strings (with or without a '0x' prefix). It is a straightforward feature addition with no security-relevant behavior change; the underlying hex parsing already existed in the crate.

This commit adds new public functions that let users create Bitcoin amount values from hexadecimal strings. It is a feature addition, not a fix for a known bug or vulnerability. There is no evidence in the commit or supplied references that this change addresses a security issue.

This commit adds support for the Bitcoin network's 'pong' message type to the library. A pong is the standard reply to a ping, used to check that a peer is still alive. The change only adds new code for encoding, decoding, and testing this message type; it does not alter existing behavior or fix any vulnerability.

This commit adds a new way to encode and decode Bitcoin 'ping' network messages in the rust-bitcoin library. It is a routine feature addition: it introduces a dedicated Ping message type with proper serialization/deserialization and replaces older serialization tests with a round-trip test. There is no indication of a security bug being fixed.

This commit adds a special build-time flag named `chacha20_poly1305_fuzz` that swaps out real ChaCha20/Poly1305 cryptography with fake, deterministic no-op versions intended only for fuzz testing. The fake versions do not encrypt data and do not authenticate it; they are meant to be used only when explicitly compiling with the fuzz flag. The change itself is a test/infrastructure addition, not a normal production code path. The main risk is accidental misuse: if someone builds or ships production code with `chacha20_poly1305_fuzz` enabled, encryption and authentication would be silently disabled. The commit does not claim to fix a vulnerability and does not appear to introduce one in normal builds.

This commit only edits the project's justfile, a developer convenience script. It removes explicit Rust toolchain arguments because a newer version of the cargo-rbmt tool now handles toolchains internally. There is no change to the actual Bitcoin library code, no user-facing behavior change, and no security relevance.