rust-bitcoin

This commit is a minor code cleanup: it moves a fixed byte pattern (the Bitcoin witness commitment marker) from inside a function to the top of the file so the same constant can be reused in a test. There is no change to behavior, no bug fix, and no security impact.

This commit fixes a bug in how the rust-bitcoin library validates witness commitments in Bitcoin blocks. Under BIP141 rules, if a block contains a witness commitment, the coinbase transaction must also contain exactly one 32-byte witness reserved value, even when no other transactions use SegWit. The old code skipped this requirement when no SegWit transactions were present, which could let an invalid block appear valid. The fix moves the 'no SegWit transactions' shortcut after the commitment/reserved-value checks, matching Bitcoin Core and btcd behavior.

This is a minor code cleanup inside a single test file. It removes unnecessary cloning of test data and renames a loop variable for clarity. There is no change to production code, no security fix, and no behavior change.

This commit removes leftover configuration that skipped certain GitHub Actions jobs when the workflow was run locally using a tool called 'act'. It is a routine cleanup with no effect on the security of the Bitcoin library code users actually run.

This commit tightens input checking for Bitcoin wallet master-key creation. Previously, the library would accept any seed length when creating a BIP-32 master key, even though the standard only allows seeds between 16 and 64 bytes. Now it validates the length and rejects out-of-range seeds. It also changes how seed bytes are printed in debug logs so the full secret is no longer exposed, and compares seeds in constant time to reduce timing side-channel risk.

This commit fixes a typo in GitHub Actions workflow cache keys. The cache key was referencing a non-existent matrix variable `matrix.target` instead of the correct `matrix.fuzz_target`. This only affects how fuzzing build artifacts are cached in CI and has no security relevance to the Rust Bitcoin library itself or its users.

This change simply moves an existing automated test (Miri, a Rust memory-safety checker) from running on every pull request to running once per day, like other long-running tests. It does not change any code that users run, and it does not fix or introduce a security bug.

This commit removes a fallback for extremely unusual (and currently non-existent) computer architectures where a memory-size value might be larger than 64 bits. On such hypothetical platforms, the old code would quietly cap the value at the maximum 64-bit number. The new code instead refuses to compile/run on those platforms, because none exist today. For every real platform, the behavior is unchanged.

This commit updates an internal CI script so that any future pull request introducing backward-incompatible API changes to the already-released 1.0 crate 'bitcoin-consensus-encoding' will cause the automated build to fail. It is a process/guardrail change, not a fix for an active security flaw.

This is a small code cleanup in the Bitcoin peer-to-peer message decoder. It replaces a more verbose pattern that swapped out an internal state object with a simpler one that just takes the current value. The behavior is unchanged because the replaced value was immediately overwritten by the next state transition anyway. There is no security issue here.

This commit refactors internal helper methods in a fixed-size array type so that the safer, lower-level methods are reused instead of directly touching internal fields. It is a code-quality and safety-clarity improvement rather than a fix for a known exploitable bug. No public security advisory or researcher credit is present.

This commit is a code cleanup: it moves several helper methods (push, try_push, pop, extend_from_slice) out of a special 'safety_boundary' module into a normal implementation block. The actual behavior of the code does not change, and no security bug is fixed or introduced. The change is meant to make future safety reviews easier by keeping only truly low-level unsafe code inside the safety boundary.

This commit changes an internal helper function in the rust-bitcoin library to skip a length safety check using Rust's `unsafe` keyword. The author argues this is safe because the type already relies on an internal invariant that the length never exceeds capacity. The change is small and performance-oriented, but it increases reliance on a manually maintained safety invariant.

This commit adds a new low-level helper function called `set_len` to an internal array-like data structure (`ArrayVec`). It is marked `unsafe` and is intended to let other internal code manipulate the length of the array directly, similar to how Rust's standard `Vec::set_len` works. The commit itself does not change any public behavior or fix a known bug; it is a small internal API addition.

This commit adds a Rust compiler annotation to a helper function so that if it ever causes a program crash due to being full, the error message points at the code that called it rather than the helper itself. It does not change what the program does, only the quality of the crash diagnostic. There is no security vulnerability here.

This commit adds a small helper method to an internal array-backed vector type. It simply exposes the unused portion of the underlying array as a mutable slice of uninitialized memory. There is no security issue visible in the change itself.

This is a small internal code cleanup in the rust-bitcoin library. A function called `push` that adds items to a fixed-size array was rewritten to call a newer helper function (`try_push`) instead of doing the work directly. The behavior is unchanged: it still panics if the array is full, just with a slightly different panic message. There is no security issue here.

This commit fixes a safety check in the HMAC code. Previously, the code only verified in debug builds that a hash engine's block size did not exceed 128 bytes. In release builds, an oversized block size would cause the code to write past the end of fixed 128-byte internal buffers, leading to incorrect HMAC results or memory corruption. The fix makes this check run unconditionally by changing a debug-only assertion into a regular assertion.

This commit adds convenience helper methods that let developers sign Bitcoin transaction hash values more directly. It does not change any security-critical behavior; the same cryptographic signing operations were already available through other functions. The change is purely an API usability improvement.

This is a small API ergonomics change in a Rust Bitcoin library. A function called tap_tweak is changed so callers pass a reference to the key instead of giving up ownership of the key. It does not fix a bug or vulnerability; it makes the library easier to use in code that holds key references.

This commit only regenerates a documentation file that shows the project's internal dependency tree. No program code was changed, so it cannot introduce or fix a security vulnerability on its own.

This commit is a routine release-preparation change. It bumps the version number of the `bitcoin_hashes` crate from 0.20.0 to 0.21.0, updates the project's lock files, and adds a changelog entry summarizing prior changes. There is no code change that fixes or introduces a security issue in this commit itself.

This is a purely cosmetic code-formatting commit. It only reorders imports, rewraps long lines, and collapses or expands function bodies to match the latest rustfmt nightly style. No program logic, behavior, or security properties were changed.

This change fixes how a Bitcoin-related Rust library reads compact-size numbers in BIP158 compact block filters. Previously, if the encoded element count was malformed, the code silently treated it as zero, making the filter look empty. Now it returns an error instead. This could have let an attacker or buggy peer make a node believe a filter contained no matches when in fact the data was just corrupt.

This commit only adds a new error variant to the BIP158 block filter error type. It does not change any parsing logic, fix a bug, or alter behavior. It is a preparatory code change for a future commit and has no security impact on its own.