rust-bitcoin

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.

This is a routine code cleanup change. It replaces an internal helper macro that generated `to_hex` methods with manually-written, equivalent `to_hex` methods that are marked as deprecated. The public API behavior stays the same; callers will just receive a deprecation warning encouraging them to use Rust's standard `format!("{var:x}")` instead. There is no security fix or vulnerability here.

This commit is a routine code reorganization. It moves a Rust macro called impl_array_newtype from one internal location to a shared include file and updates call sites to use the new location. No behavior changes, bug fixes, or security fixes are visible in the diff.

This commit fixes a design bug in a Rust Bitcoin library. The library claimed a certain internal trait called Tag was 'sealed' (meaning only the library authors could add new types that satisfy it), but it actually was not sealed. The commit properly seals it so outside users cannot create new Tag types. This is a defensive API-correctness change, not a fix for an active security vulnerability. It prevents future misuse rather than closing an exploitable hole.

This commit only fixes typos, grammar mistakes, and formatting in documentation comments. No code behavior changes. There is no security issue.

This is an automated code-formatting commit. It only reorders import and module declarations to match the latest rustfmt nightly style. No logic, behavior, or security-sensitive code was changed.

This commit only fixes spelling mistakes in code comments and documentation (changing 'occuring' to 'occurring' and adding a missing 'when'). No program logic, behavior, or security properties are changed.