rust-bitcoin

This commit only edits changelog Markdown files. It documents that several prior releases were yanked from crates.io because their required Rust version was raised too aggressively, and it adds notes about newer replacement releases. There are no code changes, no bug fixes, and no security patches in the diff.

This is a one-word documentation fix in a Rust macro. The generated documentation for a cryptographic tag structure was accidentally referring to a non-existent variable name, so it displayed broken placeholder text like '[`$hash_name`]' instead of the actual tag name. The change makes the docs show the correct tag name. There is no code behavior change and no security impact.

This commit only adds new unit tests to verify that a previously changed function, Target::from_compact, returns zero when a Bitcoin 'compact' difficulty value overflows a 256-bit target. It does not change any production code. The tests confirm the overflow behavior and check values right at the overflow boundary.

This commit fixes a bug in how rust-bitcoin converts Bitcoin 'compact' difficulty targets into full numeric Target values. Previously, if the compact value encoded a number too large to fit in a valid Target, the code would silently produce a truncated/wrapped result instead of treating it as invalid. The fix makes overflow behave like an invalid negative mantissa: return zero. This aligns the library with Bitcoin Core's consensus behavior, reducing the risk of consensus divergence or incorrect difficulty calculations.

This commit adds a small convenience method that lets any hash type compute a hash from a chunk of data in a single call. It is a pure API addition with no changes to existing behavior, no bug fixes, and no security-related content.

This commit fixes a bug in how the library counts 'signature operations' (sigops) in Bitcoin scripts. A small cache that remembers recently pushed numbers was not being cleared after signature-checking opcodes. This could cause a later multi-signature operation to incorrectly reuse a stale number, making the sigop count too low or too high in edge cases. The fix resets the cache whenever a signature opcode is seen, matching Bitcoin Core's consensus behavior.

This commit fixes a test-only code generator for a Bitcoin network data structure so that the generated examples respect the same padding rule used by the real decoder. It only affects fuzz/property tests and does not change production parsing or network behavior.

This commit fixes a panic (crash) in a test-only feature called 'arbitrary' that generates random fake user-agent strings for fuzz testing. The panic happened because the random generator could produce characters or lengths that the UserAgent constructor rejects. It is not a normal runtime bug in Bitcoin networking code, but it could cause fuzz tests or property-based tests to crash unexpectedly.

This commit fixes a mismatch in test-only code between how fake network addresses are randomly generated and how the real decoder validates them. It does not change any production parsing or network logic, so it cannot be exploited by an attacker. The change only makes property-based tests more realistic and avoids false test failures.

This commit is a pure code-style refactor. It rewrites the same multisignature-pattern check using a newer Rust syntax (let-else) that flattens nested if-let blocks. The author explicitly states there are no behavioral changes, and the diff shows the same checks in the same order with the same early returns.

This commit fixes a bug in how the library decides whether a Bitcoin script is a classic 'multisig' script. Before the fix, the final opcode that states how many public keys are required could be something other than a normal number-pushing opcode (for example, a reserved or meaningless opcode), and the code would still treat the script as a valid multisig. After the fix, only opcodes that push a number matching the actual count of public keys are accepted. This could matter to any code that relies on is_multisig() to classify or validate scripts, because a misclassified script could lead to wrong policy decisions, fee calculations, or wallet behavior.

This commit fixes a fuzz-testing helper so that randomly generated fake Bitcoin transactions follow the same rules that the real transaction decoder enforces. It does not change normal transaction handling, network behavior, or wallet logic; it only affects test code used to fuzz the library.

This commit is a routine internal code reorganization. It moves a helper function that computes a Taproot tweak hash from one module to another and removes an extension trait that was only used to attach that function. There is no security fix or behavior change visible in the diff.

This commit is a code cleanup (refactor) that splits one combined error type into two separate error types for parsing BIP32 derivation paths. It does not change the actual parsing rules or fix any security bug. It only changes how error messages are categorized internally, making the API clearer for developers. There is no indication this addresses a vulnerability.

This commit is a code cleanup in the rust-bitcoin library. It splits one general BIP32 derivation error type into several more specific error types and renames the old one. It does not change how keys are actually derived or add any new security behavior; it only changes how error conditions are named and reported to programmers.

This commit only adds a new test file and a development-only dependency (serde_json) to verify that a recently added serde feature serializes byte arrays as expected. It does not change any production code, fix any bug, or alter any security-relevant behavior. There is no security issue here.

This commit only updates generated API listing files (text snapshots of public symbols). It shows that some serde helper modules moved from the `bitcoin_primitives` crate to the `bitcoin_consensus_encoding` crate and that two external crates (`hex`, `serde`) are now re-exported. There is no actual code change in the diff, and nothing here indicates a security fix or vulnerability.

This commit is a routine code reorganization: it moves a serde helper module from one internal crate to another and updates import paths. There is no change to how data is encoded, decoded, or validated, and no security bug is introduced or fixed.

This is a small Rust crate housekeeping change. The `hex` crate was already part of the public API of `consensus_encoding`, but it was not re-exported at the crate's top level. The commit adds that re-export so downstream users can access the same `hex` version the crate uses. There is no bug fix, behavior change, or security patch in the diff.

This commit only adds the serde library as a dependency to a Rust Bitcoin sub-crate and wires up feature flags. It does not change any logic, parsing, serialization, or security-sensitive code. There is no indication of a vulnerability or security fix.

This is a routine internal code cleanup in the rust-bitcoin library. It replaces one way of turning data into hex text with another, simpler in-house implementation. There is no indication of a security bug being fixed.

This commit only updates three text files that list the project's public API surface. It removes entries for some internal macros and a module that are no longer publicly exposed. There are no code changes, no bug fixes, and no security relevance visible in the diff.

This commit is a routine internal code cleanup. It moves a compile-time assertion helper macro from a dedicated 'macros' file into the main library file and deletes the now-empty macros file. There is no user-facing behavior change and no security relevance.

This commit simply deletes unused and already-deprecated helper macros from an internal Rust source file. No code that was actually in use is changed, and no security-sensitive behavior is modified. It is a routine cleanup with no security impact.

This commit removes an unused internal macro wrapper. It is a straightforward code cleanup with no functional change and no security relevance.