rust-bitcoin

This commit is a routine code reorganization: it moves two related data types, FilterHash and FilterHeader, from the main bitcoin crate into the p2p crate because they are used in peer-to-peer network messages. It also removes one test assertion that checked a now-removed helper method. There is no security fix or vulnerability here.

This commit is a routine release-tracking change. It bumps the version number of the `bitcoin-primitives` crate from `1.0.0-rc.0` to `1.0.0-rc.1` in lock files and dependency manifests, and replaces placeholder "TBD" strings in deprecation notices with actual version numbers. There are no functional code changes and no security implications.

This is a routine code cleanup in an example file. A developer replaced one function call with another that does the same thing, because the old function name is being retired. There is no security issue here.

This is a one-line change in a test file that swaps a deprecated type name for its newer replacement. It has no security relevance: it does not alter production code, cryptographic logic, parsing, network handling, or any behavior visible to users of the library.

This commit changes version constraints for several in-development (release candidate) internal dependencies so Cargo will use an exact version rather than automatically picking a newer release candidate. It is a build/maintenance change to prevent unexpected dependency resolution, not a fix for a security vulnerability.

This commit creates a brand-new, empty placeholder crate named `bitcoin-bip158` inside the rust-bitcoin workspace. It adds no executable code, no network functionality, no cryptographic operations, and no changes to existing crates. It is purely a project-structure refactor in preparation for later moving BIP-158 filter code out of the main `bitcoin` crate.

This commit adds a small, public helper function to create a new type of Bitcoin address called 'pay-to-anchor' (P2A). It is a pure feature addition with no visible bug fix or security-related change. There is no indication of a vulnerability being patched.

This is a routine release-tracking commit. It bumps the version number of the `bitcoin-units` crate from `1.0.0-rc.2` to `1.0.0-rc.3`, updates other crates in the same project to depend on the new version, refreshes lock files, and adds a changelog note that a recent pull request now allows underscores as separators in `Amount` values (for example, writing 1_000_000 instead of 1000000). There are no code changes in this commit itself.

This commit only fills in placeholder version numbers in deprecation warnings. It does not change any program behavior, fix any bug, or introduce any security issue. It is a routine documentation/metadata cleanup.

This commit changes a single version requirement in a Rust package file so that a pre-release dependency is pinned to an exact version rather than allowing newer release-candidate versions. It is a build-stability fix, not a security patch. There is no code change that fixes a vulnerability or changes runtime behavior.

This is a routine code cleanup inside test code only. It swaps deprecated function calls for newer, non-deprecated equivalents in a Rust unit test file. There is no change to production behavior, no bug fix, and no security relevance visible in the commit.

This commit is a routine cleanup that swaps deprecated type names for their newer replacements in test files only. It does not change any production code, behavior, or security properties.

This commit only adds a missing changelog entry for a previously released version of an internal Rust library. It documents two routine maintenance items: raising the minimum supported Rust version and adding a dependency. There is no code change and no security relevance.

This commit is a routine version bump for an internal helper crate. It only changes version numbers in package files and a changelog entry. There is no code change, no bug fix, and no security issue visible in the diff.

This commit is a code-quality cleanup, not a security fix. It adds a `let _ = w[15];` line in two SHA hashing implementation files solely to silence a new Rust clippy lint about an unused assignment inside a macro on the final round of SHA-256 and SHA-512. The generated machine code and behavior are unchanged.

This commit adds a single annotation telling the Rust linter (clippy) to ignore a 'function is too long' warning on an internal helper function. It does not change any executable code, behavior, or data handling. There is no security relevance.

This commit adds convenience Rust traits (+= and -= operators) for a wrapper type called NumOpResult. It does not fix a bug or change existing behavior; it only makes it easier to add or subtract values that are already wrapped in a NumOpResult. There is no security relevance in the change itself.

This commit adds convenience operators (+= and -=) for a special result wrapper around Bitcoin amount types. It does not change how amounts are validated or how overflow is handled; it only lets programmers write `res += amount` instead of `res = res + amount`. There is no security bug visible in the change.

This commit simply moves existing Rust code from one file to another without changing what the code does. It is described by the project as an internal cleanup with no logic change, and the diff confirms that the implementations were copied verbatim.

This commit adds a new way to encode and decode Bitcoin peer-to-peer (P2P) network messages in the rust-bitcoin library. It is a feature/refactoring change that introduces a new 'consensus_encoding' implementation for v1 network messages, replacing the old serialization approach in an example program. There is no indication this fixes a security bug or introduces a vulnerability.

This commit refactors how Bitcoin peer-to-peer address errors are reported. It replaces a generic input/output error type with a new, more specific error type for addresses that cannot be routed over normal internet connections (Tor, I2P, CJDNS). This is a routine API cleanup, not a fix for an active security vulnerability. The change is part of a larger effort to reduce internal package dependencies.

This commit refactors how the Bitcoin P2P 'feefilter' message is encoded and decoded. It introduces a dedicated FeeFilter wrapper type and uses a new consensus-encoding crate. The change is primarily a code-quality and API-consistency improvement; it does not appear to fix a known security bug, but it does slightly harden handling of malformed fee-filter values by centralizing the logic.

This commit adds new encoding and decoding logic for Bitcoin P2P network command strings (the 12-byte labels on messages like 'version' or 'ping'). The decoder trims trailing zero padding and checks that the remaining bytes are plain ASCII before converting them to a Rust string. The conversion uses an 'unchecked' UTF-8 function, but only after an ASCII check, so it is safe in itself. The change is a routine protocol implementation addition; there is no disclosed security bug or fix.

This commit is a routine code reorganization: it moves the BIP-152 compact block module from the main `bitcoin` crate into the `p2p` crate, where it is more logically located. It also replaces an auto-derived hex formatting trait with a manual implementation for one small type. There is no security fix or behavior change visible in the diff.

This commit refactors how Bitcoin Merkle roots are calculated so the code works even when the optional 'alloc' memory allocator feature is disabled. It replaces a growable vector with a fixed-size 15-slot array, which limits the no-alloc path to at most 32,767 transaction IDs. The change is a feature-portability improvement, not a security fix, and it explicitly returns None when the no-alloc limit is exceeded rather than overflowing or corrupting state.