rust-bitcoin

This commit only adds two automated formal-verification test cases (Kani proofs) that check Bitcoin's variable-length integer encoding round-trips correctly. It does not change any production code, fix a bug, or introduce a security-relevant behavior change. There is no indication of a vulnerability or security patch.

This commit is an automated code-formatting run by rustfmt. It only changes whitespace, line breaks, import order, and other stylistic details across 18 files. No program logic, security behavior, or functionality was altered.

This commit only changes test code. It expands existing unit tests for the AddrV2 network address type so that deserialization is checked with both the old `deserialize` helper and a newer `encoding::decode_from_slice` function. No production code was modified, so it cannot directly introduce a runtime security vulnerability.

This commit adds the ability to decode (read/parse) a newer Bitcoin peer-address format called AddrV2. Before this change, the code could encode (write) these addresses but apparently could not decode them. The new decoder checks that address lengths match what each network type expects, rejects some invalid address encodings (like wrapping an old Tor or IPv4 address inside IPv6), and reports errors cleanly. It is a normal feature-completion patch, but because it handles untrusted network input, any mistakes here could create parsing bugs.

This commit only updates a test file. It refactors an existing unit test for the `AddrV2` network address type so that expected byte sequences are stored in variables and also compared against a second serialization helper (`encoding::encode_to_vec`). There is no change to production code, no bug fix, and no security-related behavior change.

This commit adds a new way to serialize Bitcoin peer-to-peer address objects (AddrV2) using a state-machine style encoder. It is a feature/refactoring change that introduces a new code path for encoding addresses, but does not by itself fix a known security bug or introduce an obvious vulnerability. The new encoder mirrors the existing consensus_encode logic, so the main risk is a subtle implementation bug in the new encoder that could cause incorrect serialization or a panic.

This commit only updates automatically-generated API snapshot files to reflect a new MuHash type that was added in a previous code change. No actual source code is modified, and there is no security fix or vulnerability here.

This commit adds a new public type called MuHash to the rust-bitcoin hashes library. It is purely a wrapper around a 384-byte byte array so that downstream projects can label muhash3072 digests with a meaningful Rust type. The commit does not implement the hash algorithm itself, change any existing behavior, or fix any bug. There is no security-relevant change.

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

This commit fixes a panic (sudden crash) in a Bitcoin transaction-signing helper. The function `spend_utxo` previously assumed that a referenced transaction output always existed, and used unchecked array indexing. If the output was missing, the program would crash instead of returning a proper error. The fix replaces the unchecked lookup with a bounds-checked one that returns a clean error.

This commit only adds a new unit test that checks whether an error message is non-empty and, when the standard library is available, whether the error has an underlying cause. It does not change any production code, fix a bug, or alter behavior. There is no security relevance.

This commit only adds new unit tests for the ScriptBuf type. It does not change any production code, fix bugs, or alter behavior. There is no security relevance.

This commit only adds new unit tests that check error messages and error chaining for a Bitcoin transaction witness decoder. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit simply reorganizes existing test code. It takes a portion of one unit test and moves it into a separate, standalone test function. There are no changes to production code, no bug fixes, and no security-relevant behavior changes.

This commit only adds new unit tests for the Witness type in the rust-bitcoin library. It does not change any production code, so it cannot introduce or fix a security vulnerability on its own.

This commit simply updates a GitHub Actions configuration file to use a newer stable version of the Rust compiler (1.93.0 instead of 1.92.0). It does not change any application code, cryptographic logic, network handling, or user-facing behavior. There is no security issue here.

This commit is a simple renaming of error types from names ending in 'DecodeError' to 'DecoderError' to match the project's existing naming convention. It does not change any behavior, logic, or security properties of the code.

This commit fixes a potential integer overflow when calculating how much memory to reserve while decoding Bitcoin transaction witness data. The overflow could only happen on 16-bit machines, which are extremely uncommon today. The fix replaces regular addition with saturating addition, so the value stops growing at the maximum instead of wrapping around. This is a defensive hardening change rather than a confirmed exploitable vulnerability on typical hardware.

This commit only updates generated API tracking text files. It records two newly added public functions on an error type in the SHA-256 module so the project's automated API-surface checks stay in sync. There is no code change, no bug fix, and no security relevance.

This commit adds standard encoding and decoding support for the InventoryPayload type in the peer-to-peer message module. It is a routine implementation of serialization traits and does not, on its own, change any security-sensitive behavior such as validation limits or memory allocation rules. There is no indication in the commit that this fixes a vulnerability.

This commit adds the ability to convert strings into two internal numeric types, Target and Work, used in Bitcoin's proof-of-work calculations. It is a routine feature addition with no security-relevant behavior change; it only provides parsing where only display existed before.

This commit adds a new feature: the ability to parse a 256-bit unsigned integer (U256) from a decimal string, similar to how you might type a large number into a program. It is a straightforward feature addition with no obvious security bug. The code carefully checks for empty input, invalid digits, non-ASCII characters, and overflow beyond the maximum U256 value.

This commit only adds a new unit test. It checks that when a SHA-256 hashing engine is paused mid-way through data (at a non-block-aligned point), the error object contains enough information to build a second engine that finishes hashing and produces the same final result. There is no code fix, behavior change, or security patch here.

This change enriches an error type in the SHA-256 hashing code. When a caller asks for the internal 'midstate' snapshot at a non-aligned point, the error now also returns the nearest aligned snapshot and any leftover bytes, so the caller can resume hashing later. It is a feature/API improvement, not a fix for an active security flaw.

This commit only adds new unit tests to verify how an existing error type is displayed and how it reports its underlying cause. It does not change any production code, fix a bug, or alter behavior that could affect security.