rust-bitcoin

This commit fixes a typo in a documentation comment. It changes the phrase 'to usually to encode' to 'to encode' in a source code file. There is no change to program logic, no security fix, and no functional impact.

This commit removes an automated WebAssembly (WASM) test job from the project's continuous integration (CI) pipeline. The job tested only the 'hashes' sub-crate. The stated reason is that the job 'breaks all the time.' There is no code change to the library itself, and nothing in the commit suggests a security issue.

This commit only updates generated API text files that list what traits and methods are publicly available. It adds entries showing that a particular error type now implements standard Rust display and error traits. There is no code change, no bug fix, and no security relevance.

This commit is a routine code-quality fix. It adds the standard Rust error boilerplate (Display and std::error::Error implementations) to a missing-denomination error type and reorders similar boilerplate in another file. There is no security-relevant change.

This commit only moves existing code around. It reorders where certain `From<Infallible>` implementations and error trait implementations appear in the source files so they follow a consistent layout convention. No behavior, logic, or security properties of the code are changed.

This commit only updates generated API text files that list what types and functions are publicly visible in the Rust library. It does not change any actual source code, behavior, or fix any problem. It is essentially a documentation refresh for the library's public interface.

This is a trivial code cleanup: it removes unnecessary 'core::' prefixes from formatting-related names in a Rust source file. The behavior of the program is unchanged, and there is no security relevance.

This commit only updates auto-generated API snapshot text files used to track the public Rust interface. It does not change any source code, behavior, or fix any bug. The files were regenerated with a tool (`just check-api`) so the recorded API matches recent code changes made in earlier commits. There is no security relevance.

This commit only updates generated API text files that list what traits and methods are publicly available in the library. No actual source code, logic, or behavior changed. It is a documentation/tracking update, not a security fix or vulnerability.

This commit adds standard Rust traits (`Clone` and `Debug`) to a collection of data-encoding helper structs in the rust-bitcoin library. These traits let developers duplicate encoder/decoder objects and print them for debugging. There is no security vulnerability here; it is a routine API-quality improvement.

This commit simply adds the ability to duplicate (clone) several decoder helper objects in the Rust Bitcoin library. It is a routine feature addition with no security relevance visible in the code or commit message.

This commit adds standard Rust helper traits (Debug and Clone) to a set of data encoder/decoder structs in the rust-bitcoin library. These traits only affect how developers can print, inspect, or duplicate encoder/decoder objects; they do not change serialization logic, parsing rules, or security behavior. There is no indication this fixes a vulnerability.

This commit adds a missing Debug formatting implementation for a six-element decoder helper in the Rust Bitcoin library. It is a routine code-quality fix with no security relevance.

This commit simply adds the standard Rust `Debug` trait to six empty marker types used for tagging different kinds of Bitcoin scripts. It is a routine, non-functional code-quality change with no security relevance.

This commit only updates generated API text files that list what types and functions are publicly visible in the library. It does not change any actual source code, behavior, or fix any problem. It is a documentation-like housekeeping change.

This commit simply removes an automated code-formatting check from the project's continuous integration (CI) pipeline and deletes the related contributor guidance. It does not change any library code, cryptographic logic, or network behavior, and it introduces no security vulnerability.

This commit simply adds the ability to duplicate (clone) a helper object called SighashCache that is used to speed up Bitcoin signature-hash calculations. It does not change any existing behavior, fix a bug, or alter security logic. There is no indication this is a security patch.

This is a routine cleanup of a GitHub Actions CI workflow. It removes one unused 'git fetch' step that was reportedly causing problems after code merges. There is no change to the actual Bitcoin library code, no security fix, and no vulnerability.

This commit refactors how Bitcoin peer-to-peer messages request blocks and headers. It replaces a plain list of block hashes with a dedicated 'BlockLocator' type and adds a helper to build locators in a logarithmic pattern (like Bitcoin Core). There is no direct security fix here; it is a structural improvement that makes the library behave more like Bitcoin Core and could indirectly reduce network/DoS risks by capping locator size and producing better locators.

This is a small internal cleanup change in the rust-bitcoin library. It swaps some low-level uses of one public-key type for another equivalent type that now carries extra parity information. There is no indication this fixes a security bug or changes behavior visible to users in a risky way.

This commit is a routine internal API cleanup in the rust-bitcoin library. It changes one function so it accepts the project's own public-key type instead of a lower-level secp256k1 public-key type, removing unnecessary conversions at call sites. There is no indication this fixes a security bug or introduces a vulnerability.

This commit is a purely stylistic change in the Rust Bitcoin library. It rewrites conditional compilation attributes (the Rust equivalent of #ifdef feature flags) from a single combined form to a stacked form. For example, #[cfg(all(feature = "hex", feature = "alloc"))] becomes two separate #[cfg(...)] lines. This has no effect on which code is compiled or how the library behaves, and it does not fix or introduce any security issue.

This commit is a purely cosmetic refactoring of Rust conditional-compilation attributes. It splits combined `#[cfg(all(...))]` expressions into two stacked `#[cfg(...)]` attributes, which is a supported Rust syntax and does not change which code gets compiled under which conditions. There is no security relevance.

This commit only adds a coding-style rule to the project's documentation. It tells developers to prefer stacking multiple #[cfg] attributes instead of combining them with #[cfg(all(...))]. No code behavior changed, and there is no security impact.

This commit is a purely cosmetic change in how Rust conditional compilation rules are written. It splits combined conditions like `cfg(all(A, B))` into two separate stacked `#[cfg(A)]` and `#[cfg(B)]` lines. The actual conditions and the resulting compiled code are unchanged, so there is no security or functional effect.