rust-bitcoin

This change only fixes how hash performance is measured in benchmark tests. It does not change any real hashing code that users or applications rely on, so it has no security impact on the library itself.

This commit simply makes two existing data types (FilterHash and FilterHeader) easier to import from the top level of the new 'p2p' crate. It is a straightforward API-compatibility cleanup after a crate split and does not change any behavior, logic, or security-sensitive code.

This commit adds a new public function for calculating Bitcoin's next mining difficulty target and updates the library to support a recent test network rule (BIP-94). It is a feature addition that mirrors Bitcoin Core's consensus logic. There is no direct evidence in the commit that it fixes an active security bug, but any mistake in difficulty-target arithmetic could, in principle, cause a node or wallet built on this library to disagree with the rest of the Bitcoin network about which chain is valid. The change is well-documented, heavily tested, and appears to be a straightforward port of existing reference code.

This commit is a harmless code-quality cleanup. It swaps two bitwise AND operators (`&`) for logical AND operators (`&&`) in functions that check Bitcoin transaction sequence numbers. The author explicitly states there is no logic change. Because both operands are already boolean expressions, the result is identical; the only difference is that `&&` skips evaluating the second expression when the first is false, which is slightly more efficient.

This commit only changes test code. It swaps one set of internal helper functions for another inside unit tests for the Bitcoin network 'magic' bytes. No production code is altered, so it cannot affect security.

This commit adds new serialization/deserialization code for the Bitcoin network 'magic' bytes (the 4-byte identifier at the start of P2P messages). It is a routine feature addition that mirrors existing consensus encoding support. There is no indication of a security bug, fix, or vulnerability in the change itself.

This commit only reorders the text in automatically generated API snapshot files so they match the new output from a macro change. No actual code or library behavior changed, and there is no security relevance.

This commit is a routine code cleanup. It replaces several nearly identical error-type definitions with a single Rust macro, reducing duplicated boilerplate. There is no change to how the library behaves, what data it accepts, or how it handles errors.

This commit is a straightforward internal code cleanup: it replaces several hand-written composite encoder types with a Rust macro that generates equivalent types. There is no change to public behavior, no bug fix, and no security relevance visible in the diff or commit message.

This commit fixes a bug in how Partially Signed Bitcoin Transactions (PSBTs) read and write their internal 'key' fields. The old code assumed the key's type number always fits in one byte when encoded as a compact size. That assumption is wrong for large type numbers, so the code could misread the key's length and either reject valid PSBTs or, in the worst case, allocate too much memory. The fix makes the encoder and decoder correctly account for the actual number of bytes the type number occupies.

This commit only updates a documentation file (docs/dep-tree) that shows the dependency tree of the project's Rust crates. No source code, build scripts, or configuration files were changed. It is a routine documentation refresh with no security relevance.

This commit only updates generated API snapshot text files to match a recent code change. It renames a function parameter from 'data' to 'inp' and changes a return type description from the full type name to 'Self'. These are documentation-like API snapshots, not actual source code changes, and they have no effect on program behavior or security.

This commit fixes a bug in the SHA3-256 hashing code in rust-bitcoin. Previously, when data was fed in chunks (rather than all at once), the code incorrectly added end-of-message padding after every chunk. That produced the wrong hash for any multi-chunk input. The fix buffers partial blocks and only applies padding once at the end. The commit adds a regression test that hashes byte-by-byte and compares the result to the known correct output.

This commit is a straightforward code reorganization: it moves the MerkleBlock and PartialMerkleTree implementation from the main `bitcoin` crate into the `p2p` crate, where it is more logically grouped with peer-to-peer message types. The actual logic, tests, and test data files are copied almost unchanged. There is no indication this fixes or introduces a security vulnerability.

This commit is a routine build-tooling update. It replaces an older set of maintainer helper scripts with a new Rust-based tool called cargo-rbmt, and updates the project's justfile (a command runner) accordingly. There is no indication this change fixes or introduces a security problem.

This commit only adds a new test to verify that HMAC hashing still produces the correct result when data is fed in one byte at a time. It does not change any production code, fix a bug, or alter behavior. The existing code already handled incremental input correctly; the change simply adds missing test coverage.

This commit only adds new unit tests that check the hexadecimal string representation of existing maximum mining target constants for Bitcoin's mainnet, testnet, regtest, and signet networks. It does not change any production code, library behavior, or security-sensitive logic. It is purely a regression test addition.

This commit adds common Rust traits like Copy, Clone, Eq, Ord, and Hash to ChaCha20-Poly1305 cryptographic types. It is a routine developer-facing API improvement. The commit deliberately avoids adding Debug to types that hold secret keys or nonces to prevent accidental leakage in logs. There is no direct security vulnerability in the diff itself.

This commit fixes a validation gap in how the library handles Partially Signed Bitcoin Transactions (PSBTs). A PSBT can include a reference to a previous transaction output (the 'non-witness UTXO') that doesn't actually exist. Before this fix, the library would not reject this, which could allow malformed or malicious PSBTs to be processed. The fix adds a bounds check so that if a PSBT input claims an output index that is too high, deserialization returns a clear error instead of silently continuing. The issue was found by differential fuzzing against Bitcoin Core.

This commit only updates generated API snapshot files (text listings of public types and functions) to reflect a new ArrayRefEncoder type and a change in BlockHashEncoder's constructor. No actual source code implementing behavior is modified, and nothing in the commit suggests a security fix or vulnerability.

This tiny change switches how a 32-byte Bitcoin block hash is encoded internally. Instead of copying the hash bytes into a new owned array before encoding, it now encodes directly from a borrowed reference to the existing bytes. This is a routine performance and memory-efficiency cleanup. There is no direct evidence in the commit that it fixes a security bug.

This commit adds a new helper type that lets the library encode a borrowed fixed-size byte array without copying it. It is a straightforward performance and API improvement with no security-relevant behavior change.

This is a small internal code cleanup in the rust-bitcoin library. It changes how Bitcoin hash types (like transaction IDs) are printed as text, making them reuse formatting code from a lower-level module instead of defining it separately. There is no indication this fixes a security bug or introduces a vulnerability.

This commit fixes a formatting bug in how Bitcoin transaction and block hashes are displayed when the library is built without the optional 'hex' feature. Some hash types in Bitcoin are conventionally shown in reverse byte order. The old no-hex debug code ignored that convention and always printed bytes forward, so a developer could see a hash string that looks wrong compared to the rest of the ecosystem. It is a display bug, not a cryptographic or consensus bug, and it does not directly let an attacker steal funds or corrupt data.

This is a code cleanup change in the rust-bitcoin library. It removes automatic error conversions (From trait implementations) for certain decoder errors and replaces them with explicit .map_err() calls. The behavior of the code appears functionally identical—errors are still propagated the same way. There is no indication this fixes a security vulnerability.