rust-bitcoin

This commit only changes how hash values look when printed for debugging. It adds the type name (like 'Txid(...)') around the hexadecimal hash string so developers can more easily tell which kind of hash they are looking at. It does not change how hashes are compared, stored, serialized, or used in Bitcoin logic.

This commit only changes how hash values look when printed in debugging output. Instead of showing just the raw hex string, the debug format now also includes the type name, like 'Txid(bitcoin_hashes::sha256d::Hash(...))'. It does not change any behavior that handles real bitcoin data, secrets, or network messages, and it introduces no security risk.

This commit is a routine internal dependency cleanup. The project had been re-exporting an unstable version of a hex-encoding helper crate, but its policy says the main crate must only re-export stable versions. The change swaps the public re-export to the stable version while keeping the unstable version as a private internal dependency for code that still needs it. There is no security bug being fixed here.

This change lets users of the library who don't use the standard Rust library ('no_std' environments, common in embedded or blockchain hardware) benefit from faster SHA-256 hashing via CPU-specific instructions. It adds an optional helper crate that detects CPU features in 'no_std' mode, similar to how the standard library already does it. There is no direct evidence in the commit that this fixes a security vulnerability; it is a performance and portability improvement.

This commit is a routine performance optimization. It rewrites how a Bitcoin transaction witness is built from an iterator so that it uses a single decoder pass instead of allocating many small temporary vectors. There is no indication of a security bug being fixed.

This commit adds standard encoding and decoding support for the Bitcoin P2P 'headers' message type in the rust-bitcoin library. It is a routine feature implementation with no visible security fix or behavior change to existing code paths.

This commit adds new serialization/deserialization code for a Bitcoin P2P message wrapper type called NetworkHeader. It is a routine feature addition that implements internal encoding traits so NetworkHeader can be used inside another message type (HeadersMessage). There is no indication in the commit of a security bug, vulnerability, or fix.

This commit changes how Bitcoin block headers received over the peer-to-peer network are parsed. Previously, the code would reject a headers message if the trailing byte (which indicates how many transactions follow) was anything other than zero. The commit introduces a wrapper type that accepts any value for that byte. The stated reason is future-proofing: if Bitcoin ever uses that byte for something useful, clients using this stricter library would be unable to follow the longest chain because they'd reject valid messages. There is no claim in the commit that this fixes an active security bug, and the change is framed as a protocol-compatibility improvement.

This commit only changes test code. It updates a handful of unit tests in the Merkle tree module to use a newer internal encoding helper (`encoding::encode_to_vec` / `encoding::decode_from_slice`) instead of the older `encode::serialize` / `encode::deserialize` helpers. No production code is modified, so it cannot affect the security of the library at runtime.

This commit adds new encoding and decoding machinery for a data structure called MerkleBlock in the library's peer-to-peer networking code. It is a routine feature addition that mirrors a similar change already made for PartialMerkleTree. There is no indication in the commit that this fixes a security bug or introduces a vulnerability.

This commit adds new serialization/deserialization code for PartialMerkleTree, a data structure used in Bitcoin peer-to-peer messages. It re-implements the existing bit-packing logic using a new internal encoding framework. There is no direct evidence of a security bug, but the change touches low-level binary parsing and could introduce subtle correctness issues if the new decoder does not exactly match the old behavior.

This commit only adds a new performance benchmark for the SHA256d hashing function. It does not change any production code, cryptographic logic, or user-facing behavior. There is no security issue.

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.