rust-bitcoin

This commit is a routine release-preparation change. It bumps the version number of the `bitcoin_hashes` crate from 0.20.0 to 0.21.0, updates the project's lock files, and adds a changelog entry summarizing prior changes. There is no code change that fixes or introduces a security issue in this commit itself.

This is a purely cosmetic code-formatting commit. It only reorders imports, rewraps long lines, and collapses or expands function bodies to match the latest rustfmt nightly style. No program logic, behavior, or security properties were changed.

This commit only adds a new error variant to the BIP158 block filter error type. It does not change any parsing logic, fix a bug, or alter behavior. It is a preparatory code change for a future commit and has no security impact on its own.

This commit only adds new regression tests for malformed BIP158 compact-size filter counts. It does not change any production code, so it cannot introduce or fix a runtime vulnerability by itself. The tests verify that truncated and non-minimal CompactSize prefixes are rejected with parse errors in the GCS filter reader's match_any and match_all methods.

This change fixes how a Bitcoin-related Rust library reads compact-size numbers in BIP158 compact block filters. Previously, if the encoded element count was malformed, the code silently treated it as zero, making the filter look empty. Now it returns an error instead. This could have let an attacker or buggy peer make a node believe a filter contained no matches when in fact the data was just corrupt.

This commit fixes a performance problem in how the library reads Bitcoin transaction witness data. Before the fix, specially crafted witness data could force the code to allocate memory one byte at a time, thousands of times in a row. That slowness could be abused to cause denial of service, especially when the code is run under fuzz testing or other instrumentation. The fix ensures the code always allocates at least 1,000 bytes at once, removing the repeated tiny allocations.

This commit only adds a new test to verify the text output format of a special internal value called LeafVersion::Future. It does not change any production code, so it cannot introduce or fix a security vulnerability by itself. The test is meant to document that a previous formatting change was a bug fix, but this commit alone does not show what that previous change was or whether it had security implications.

This commit fixes a tiny formatting bug in how a future Taproot leaf version number is printed as text. When using the alternate display mode (which adds '0x'), the width specifier was set to 2 instead of 4, so a value like 0xAB would print as '0xAB' (correct) but a value like 0x0B would print as '0x0B' (still correct because the '#' flag already accounts for '0x'). Actually, with Rust's {:#02x} for a u8, the minimum width is 2 for the whole output including '0x', so single-hex-digit values print as '0x1' rather than '0x01'. The fix ensures consistent two-digit hex output. This is a display-string correctness issue, not a memory safety or cryptographic bug, and has no direct security impact.

This commit fixes a typo in a code comment (documentation). It changes the error name mentioned in a comment from 'CAPSizeExceeded' to 'CapacityExceeded' to match the actual code. There is no change to program logic, no bug fix, and no security relevance.

This commit is a routine release-management change. It bumps the version of the `bitcoin-consensus-encoding` crate from 0.2.0 to 1.0.0, adds a changelog, and updates downstream crates and lockfiles to use the new version. There are no code logic changes, bug fixes, or security patches in the diff.

This commit only edits a README file in the consensus_encoding crate. It rewrites the crate description and replaces a release-candidate notice with a short history of how the crate was developed. No code, tests, build files, or dependencies were changed.

This commit simply moves the V1NetworkMessage struct definition and its associated implementation block next to each other in the same source file. There are no code behavior changes, no security fixes, and no functional modifications.

This commit refactors how Bitcoin network command names (like 'version' or 'ping') are stored internally. It replaces a flexible string container with a fixed 12-byte array, which removes dynamic memory allocation and tightens checks that command strings are ASCII and no longer than 12 characters. The change is mostly a defensive cleanup, but it also removes a public constructor and slightly alters how non-ASCII or malformed command strings are rejected during decoding.

This is a small internal code-quality change in the Bitcoin peer-to-peer networking library. It marks a 12-byte message command string type as Copy, which lets the compiler duplicate it more cheaply. The change removes a few unnecessary .clone() calls. There is no security issue here.

This commit only fixes spelling and grammar mistakes in code comments and documentation. No program logic, code behavior, or security properties were changed.

This commit only reformats the import statements in a single test file. No code behavior, logic, or security properties changed.

This commit only changes how two existing tests are written. It replaces manual panic-catching code with Rust's standard #[should_panic] test attribute. The tests still verify the same behavior: that decoding functions panic when decoded values do not match expected values. There is no change to production code, no security fix, and no vulnerability introduced.

This commit only updates generated API snapshot text files in the rust-bitcoin hashes crate. It removes lines that list certain public type aliases and constants from the recorded public API surface. These files are used to detect unintended API changes during CI, not to implement behavior. There is no code change, no bug fix, and no security-relevant content in the diff.

This is a routine code cleanup in the rust-bitcoin hashes library. It removes duplicate ways of asking a hash engine for the output length and byte type, directing callers to use the associated Hash type instead. The commit message explicitly says this fixes an inconsistency discovered for the sha512_256 output size, but the change itself is an API simplification, not a security patch. There is no evidence of a vulnerability being fixed.

This commit is a small internal cleanup of a fuzz test (a software self-test) in the rust-bitcoin project. It swaps one helper function for another so the test avoids an unnecessary memory allocation. There is no change to the library code that real users rely on, and nothing in the commit suggests a security vulnerability was fixed.

This commit only updates three public API snapshot files to list two newly added test helper functions, `check_decode` and `check_decoder`. These are additions to the library's test/verification tooling, not changes to production code, and there is no indication of any security issue.

This commit only adds new helper functions for unit tests and refactors existing tests to use them. It does not change any production behavior, fix a bug, or alter security-relevant code paths. There is no indication this is a security patch.

This commit only updates two documentation comments in a Rust source file. It changes how a type called Header is referenced in doc comments so the generated documentation links correctly. There is no code behavior change, no bug fix, and no security relevance.

This is a pure code cleanup change. It rewrites a decoder helper from a hand-written struct into one generated by an existing macro, without changing what the code actually does. There is no security-relevant behavior change.

This commit is a large internal cleanup in the P2P networking code. It replaces many hand-written decoder definitions with a shared macro called decoder_newtype!. There is no change to how data is parsed, validated, or what limits are enforced; the same logic is just written more concisely. It does not appear to fix or introduce any security vulnerability.