rust-bitcoin

This commit adds common Rust traits like Copy, Clone, Eq, Ord, and Hash to ChaCha20-Poly1305 cryptographic types. It is a routine developer-facing API improvement. The commit deliberately avoids adding Debug to types that hold secret keys or nonces to prevent accidental leakage in logs. There is no direct security vulnerability in the diff itself.

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 only updates generated API snapshot files (text listings of public types and functions) to reflect a new ArrayRefEncoder type and a change in BlockHashEncoder's constructor. No actual source code implementing behavior is modified, and nothing in the commit suggests a security fix or vulnerability.

This commit adds a new helper type that lets the library encode a borrowed fixed-size byte array without copying it. It is a straightforward performance and API improvement with no security-relevant behavior change.

This tiny change switches how a 32-byte Bitcoin block hash is encoded internally. Instead of copying the hash bytes into a new owned array before encoding, it now encodes directly from a borrowed reference to the existing bytes. This is a routine performance and memory-efficiency cleanup. There is no direct evidence in the commit that it fixes a security bug.

This is a small internal code cleanup in the rust-bitcoin library. It changes how Bitcoin hash types (like transaction IDs) are printed as text, making them reuse formatting code from a lower-level module instead of defining it separately. There is no indication this fixes a security bug or introduces a vulnerability.

This commit fixes a formatting bug in how Bitcoin transaction and block hashes are displayed when the library is built without the optional 'hex' feature. Some hash types in Bitcoin are conventionally shown in reverse byte order. The old no-hex debug code ignored that convention and always printed bytes forward, so a developer could see a hash string that looks wrong compared to the rest of the ecosystem. It is a display bug, not a cryptographic or consensus bug, and it does not directly let an attacker steal funds or corrupt data.

This is a code cleanup change in the rust-bitcoin library. It removes automatic error conversions (From trait implementations) for certain decoder errors and replaces them with explicit .map_err() calls. The behavior of the code appears functionally identical—errors are still propagated the same way. There is no indication this fixes a security vulnerability.

This commit only adds a documentation comment to the Target type explaining that it does not enforce a maximum value limit. No code behavior was changed, and no security vulnerability is present in the commit itself.

This commit only updates generated API snapshot files that document the public interface of the Rust Bitcoin crates. It does not change any source code, logic, or behavior. The snapshots reflect a separate, earlier code change that added lifetime parameters to encoder types. There is no security issue in this commit itself.

This commit is a purely cosmetic renaming of lifetime parameters in Rust code. It changes labels like 's, 'a, and 'e to consistently use 'e across encoder-related code. There is no functional change, no bug fix, and no security impact.

This commit is a Rust type-system cleanup. It changes a macro that creates encoder wrapper types so that every wrapper must carry a lifetime parameter, and updates all uses across the codebase. There is no change to runtime behavior, wire format, or cryptographic logic. It prevents future misuse of the macro but does not fix a known exploitable bug.

This commit is a minor internal code cleanup in the Rust Bitcoin library. It replaces a long, complex type definition inside a macro with a shorter type alias name. There is no change to how transactions are encoded, no change to public behavior, and no security relevance.

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 fixes a minor display bug in how certain Bitcoin hash values are printed as debug text when the optional 'hex' feature is turned off. Reversed hash types (like transaction IDs in Bitcoin, which are conventionally shown backwards) were being printed in the wrong order. This only affects debug/log output, not the actual hash data or cryptographic operations, so it is not a direct security vulnerability.

This is a small, safe API refactor. A helper function that writes bytes as hexadecimal text was changed to accept any iterator over bytes instead of only a fixed slice. This does not fix a vulnerability and does not change runtime behavior for existing callers.

This commit adds extra text formatting abilities (like showing numbers in hexadecimal, binary, or octal) to three simple numeric wrapper types in the rust-bitcoin library: block version, transaction version, and compact target. It is a routine usability improvement with no security relevance.

This commit only adds two automated formal-verification test cases (Kani proofs) that check Bitcoin's variable-length integer encoding round-trips correctly. It does not change any production code, fix a bug, or introduce a security-relevant behavior change. There is no indication of a vulnerability or security patch.

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 only changes test code. It expands existing unit tests for the AddrV2 network address type so that deserialization is checked with both the old `deserialize` helper and a newer `encoding::decode_from_slice` function. No production code was modified, so it cannot directly introduce a runtime security vulnerability.

This commit adds the ability to decode (read/parse) a newer Bitcoin peer-address format called AddrV2. Before this change, the code could encode (write) these addresses but apparently could not decode them. The new decoder checks that address lengths match what each network type expects, rejects some invalid address encodings (like wrapping an old Tor or IPv4 address inside IPv6), and reports errors cleanly. It is a normal feature-completion patch, but because it handles untrusted network input, any mistakes here could create parsing bugs.