rust-bitcoin

This commit fixes a validation gap in how the library handles Partially Signed Bitcoin Transactions (PSBTs). A PSBT can include a reference to a previous transaction output (the 'non-witness UTXO') that doesn't actually exist. Before this fix, the library would not reject this, which could allow malformed or malicious PSBTs to be processed. The fix adds a bounds check so that if a PSBT input claims an output index that is too high, deserialization returns a clear error instead of silently continuing. The issue was found by differential fuzzing against Bitcoin Core.

This commit is a routine internal code reorganization in the rust-bitcoin library. It moves several key-related wrapper types into a single private 'encapsulate' module and re-exports them, without changing their public behavior or adding any security fixes. There is no indication of a vulnerability being patched.

This commit is a routine code cleanup. It adds a new public constructor method called from_secp for the Keypair type and makes the existing From conversion use that constructor. It also moves an existing inner accessor method to a different spot in the file. There is no security fix or behavior change.

This commit is a code cleanup in the rust-bitcoin library. It replaces direct internal access to cryptographic key data (like reading the hidden `.0` field) with official getter methods and constructors. There is no direct evidence this fixes an active security bug, but it strengthens encapsulation so future mistakes are less likely.

This commit is a routine API cleanup: it renames a method from `into_inner()` to `to_inner()` on a public-key wrapper type and keeps the old name as a deprecated alias. There is no security bug, no behavior change, and no vulnerability introduced or fixed.

This commit is a routine API cleanup, not a security fix. It hides the internal secp256k1 public key inside the CompressedPublicKey type and replaces direct field access with a constructor (from_secp) and a getter (to_inner). That improves encapsulation but does not change how keys are validated or used. There is no evidence this fixes a vulnerability.

This commit is an automated code-formatting run by rustfmt. It only changes whitespace, line breaks, import order, and other stylistic details across 18 files. No program logic, security behavior, or functionality was altered.

This commit fixes a panic (sudden crash) in a Bitcoin transaction-signing helper. The function `spend_utxo` previously assumed that a referenced transaction output always existed, and used unchecked array indexing. If the output was missing, the program would crash instead of returning a proper error. The fix replaces the unchecked lookup with a bounds-checked one that returns a clean error.

This commit fixes a potential integer overflow when calculating how much memory to reserve while decoding Bitcoin transaction witness data. The overflow could only happen on 16-bit machines, which are extremely uncommon today. The fix replaces regular addition with saturating addition, so the value stops growing at the maximum instead of wrapping around. This is a defensive hardening change rather than a confirmed exploitable vulnerability on typical hardware.

This commit only adds a new unit test. It checks that when a SHA-256 hashing engine is paused mid-way through data (at a non-block-aligned point), the error object contains enough information to build a second engine that finishes hashing and produces the same final result. There is no code fix, behavior change, or security patch here.

This change enriches an error type in the SHA-256 hashing code. When a caller asks for the internal 'midstate' snapshot at a non-aligned point, the error now also returns the nearest aligned snapshot and any leftover bytes, so the caller can resume hashing later. It is a feature/API improvement, not a fix for an active security flaw.

This commit is a routine update to the project's automated testing setup. It replaces a set of shell scripts with a new Rust tool called `cargo rbmt` for running tests and lints in CI. There are no changes to the actual Bitcoin library code that users interact with, and no security issue is evident.

This commit only adds Clippy lint-suppression attributes (`#[allow(clippy::too_many_arguments)]`) to three internal cryptographic helper functions in the `rust-bitcoin` hashes crate. It does not change any executable code, logic, or public API. There is no security relevance: it simply tells the Rust linter to stop warning that these functions have many parameters.

This commit only adds new unit tests for an existing Rust type called NumOpResult. It does not change any production code, fix bugs, or alter behavior. There is no security issue here.

This commit is a routine code-quality refactor in the rust-bitcoin library. It wraps the underlying secp256k1 keypair type in a library-specific type so that parsing errors can be more precise and the public API is cleaner. There is no direct security vulnerability being fixed here; it is an interface improvement that may indirectly reduce misuse.

This commit adds a safety check in the rust-bitcoin library so that when a Bitcoin transaction is being decoded, the total value of all its outputs is rejected if it exceeds the protocol's maximum allowed money supply (MAX_MONEY). This prevents a class of bugs similar to the historic Bitcoin Core overflow issue referenced as CVE-2010-5139, where an impossibly large total output value could cause incorrect accounting or consensus problems.

This commit only fixes compiler lint warnings. It adds missing feature gates so that test code compiles cleanly when certain optional features are enabled or disabled. There is no change to runtime behavior, no bug fix, and no security relevance.

This change only touches an example program used for documentation and CI demos. It makes the seed argument optional by providing a documented default value. There is no security issue: the seed was already hard-coded in the comment above, and the example is not production code.

This commit simply deletes five old benchmark test files that were accidentally left behind after benchmarks were moved to a newer testing framework. It removes unused code and has no effect on the actual Bitcoin hashing library or its users.

This commit is a documentation-only cleanup. It fixes spelling mistakes, grammar, and typos in code comments, README files, and rustdoc strings. No executable code, logic, or security behavior was changed.

This commit fixes a bug in a 256-bit unsigned integer multiplication routine used by the Rust Bitcoin library. The old code produced wrong multiplication results and failed to detect when the result exceeded 256 bits. Because this arithmetic is used in Bitcoin's difficulty retargeting calculations, incorrect results could theoretically lead to wrong difficulty estimates, though the practical attack path is limited.

This commit adds a faster way to calculate SHA-256 hashes on modern 64-bit ARM processors (like Apple's M chips, AWS Graviton, and recent smartphones) by using built-in CPU instructions called ARM SHA2 crypto extensions. It mirrors an earlier change that did the same thing for x86 processors. There is no indication in the commit that this fixes a security bug; it is a performance improvement.

This commit is a routine feature addition to the Rust Bitcoin library. It introduces a new ExactSizeEncoder trait that lets callers ask fixed-size encoders how many bytes they will produce, and adds an ExactSizeIterator implementation for the byte iterator. There is no security fix or vulnerability here; it is purely an API enhancement with tests.

This commit adds a safety check in the rust-bitcoin library so that when a Bitcoin transaction is being decoded, it is rejected if it tries to spend the same coin twice within the same transaction. This prevents a known bug class (CVE-2018-17144) where duplicate inputs could cause nodes to crash or accept invalid transactions. The change also updates existing tests that accidentally used duplicate inputs.

This commit adds a Rust compiler annotation called #[track_caller] to a single function. It does not change what the program does, how it validates inputs, or how it handles errors. It only improves the quality of panic messages so that if the function panics, the reported error location points to the caller's code rather than inside this library function. There is no security fix here.