rust-bitcoin

This commit only adds a new fuzz test for an existing data type (TapLeafHash). It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit adds standard data-encoding support for a Bitcoin Taproot hash type (TapLeafHash) so it can be properly serialized and deserialized in PSBT data. There is no indication of a security bug being fixed; it appears to be a missing-feature addition.

This commit simply adds a new internal software building block (a Rust crate dependency called bitcoin-consensus-encoding) to another internal crate (taproot-primitives). It updates package lists and feature flags so the new dependency can be used in future work, but it does not change any actual logic, data handling, or security behavior. There is nothing here that directly fixes or introduces a vulnerability.

This commit adds a single line re-exporting a new Rust crate called taproot_primitives from the main bitcoin crate. It is a routine dependency wiring change with no visible security implications in the diff itself.

This commit only updates generated API snapshot text files that record which Rust traits are implemented for the library's types. The actual code change (adding or removing trait bounds on equality comparisons for a Block type) is not present in the diff; only the auto-generated documentation of the public API surface changed. There is no executable code modification, no bug fix, and no security-relevant behavior change visible here.

This commit only adds a new automated test to the project. It does not change any production code. The test demonstrates that two equivalent Bitcoin blocks—one with a cached witness root and one without—compare as equal. It is a regression test for a bug fixed in an earlier patch, not a security fix itself.

This commit fixes a bug in how Bitcoin 'Block' objects are compared for equality. The old code automatically compared every internal field, including a cached 'witness_root' value that can be missing or different depending on how the block was built. That meant two blocks with the same header and transactions could incorrectly look different, or two blocks with different cached values could look the same. The fix manually compares only the header and the list of transactions, which is the correct definition of block equality. It also adds tests to prevent the bug from returning.

This commit adds support in the rust-bitcoin P2P library for a new Bitcoin network message type called `feature`, defined by BIP 434. It also bumps the default protocol version from 70016 to 70017. This is a feature addition rather than a bug fix; there is no direct evidence in the commit that it fixes a security vulnerability. The main security consideration is that any new network message decoder could introduce parsing bugs, but the diff itself only wires up an existing `Feature` type and does not show the decoder implementation.

This commit adds a new, optional module implementing a Bitcoin protocol feature called BIP-434. It lets Bitcoin nodes advertise which new features they support during peer-to-peer handshake messages. The code only adds message parsing and serialization helpers; it does not change existing behavior or fix any reported problem. There is no indication this is a security patch.

This is a routine automated update by Dependabot that bumps the version of a GitHub-owned action used to upload security scan results. It changes one pinned commit hash in a CI workflow file and does not alter any project code, cryptographic logic, or user-facing behavior. There is no indication this introduces or fixes a security vulnerability in the rust-bitcoin library itself.

This is a routine automated update by Dependabot that bumps a GitHub Actions helper (taiki-e/install-action) used in testing workflows from version 2.79.3 to 2.79.12. It only changes which version of the action is used to install Rust testing tools in CI. There is no indication this fixes or introduces a security issue in the rust-bitcoin library itself.

This commit only updates generated text files that list the public API of the crate. The change records that the Opcode type now implements the Hash trait, which is a normal, additive feature addition. There is no code change, no bug fix, and no security relevance visible in the diff.

This commit simply adds the standard Rust Hash trait to the Opcode type, allowing Opcode values to be used as keys in hash maps and sets. There is no security-relevant change: it does not alter existing behavior, add new functionality that processes untrusted data, or fix any vulnerability.

This commit only changes test code. It renames a test and adds extra checks to make sure a Bitcoin data type (WitnessVersion) prints correctly in different number formats (decimal, hexadecimal, octal, binary). There is no change to production code and no security issue.

This commit only updates generated API snapshot text files to reflect that a Rust formatting trait was added for a Bitcoin witness-version type. There is no code change, no bug fix, and no security relevance visible in the diff.

This commit adds standard Rust formatting traits (LowerHex, UpperHex, Binary, Octal) to the WitnessVersion type, which is a small API ergonomics improvement. There is no security relevance in the diff itself.

This commit is a simple code reorganization: it moves the address module from a directory (address/mod.rs plus address/error.rs) into a single file (address.rs) and inlines the small error re-export module. No behavior changes, no security fixes, and no new functionality were introduced.

This commit is a routine Rust packaging change. It makes several internal dependency crates (base58, bech32, crypto, network, primitives, serde) publicly visible to users of the 'addresses' crate so that types from those crates can be used cleanly in the public API. There is no bug fix, behavior change, or security patch here.

This commit only fixes code style and documentation warnings (lint errors) in the addresses crate. It changes how some Rust patterns are written, adds missing documentation comments, and adjusts test code formatting. There is no change to program behavior or security.

This commit is a large internal code reorganization in the rust-bitcoin project. It moves Bitcoin address types, parsing logic, and error types from the main `bitcoin` crate into a new `addresses` sub-crate, then re-exports them so existing users of the `bitcoin` crate see the same public API. There is no indication this fixes a security bug or introduces a vulnerability; it is a structural refactoring.

This commit is a routine code reorganization in the rust-bitcoin library. It moves the `Address::from_script` method out of the main `Address` type into a new 'extension trait' called `AddressExt`. The actual logic of the function is copied unchanged. This is a design change to resolve a dependency issue (the `Params` type cannot be moved into a lower-level crate), not a security fix.

This is a small internal code cleanup in the rust-bitcoin library. It changes how Bitcoin addresses are built for certain SegWit-compatible pay-to-script-hash addresses, replacing one internal helper method with a direct opcode call. There is no indication this fixes a security bug or changes user-visible behavior.

This is a tiny internal code-quality change. It makes the default empty-script constructor reuse the existing `new()` method instead of duplicating the same one-line logic. There is no security bug being fixed and no behavior change for users.

This commit simply renames a GitHub Actions workflow file and changes its schedule from weekly to monthly. It is a routine CI maintenance change with no security relevance.

This commit seals a small helper trait called WorkExt so that outside users of the library can no longer implement it themselves. Before the change, enabling the optional `std` feature silently added a new method (log2) to the trait without a fallback, which could break any downstream code that had implemented the trait. The fix prevents that breakage and makes the library's feature setup more predictable, but it is a breaking API change rather than a traditional security vulnerability.