rust-bitcoin

This commit adds a new way to decode Bitcoin peer-to-peer network addresses in the rust-bitcoin library. It is a feature/refactoring change that introduces a new decoder implementation and swaps test cases to use it. There is no indication in the commit that it fixes a security bug, vulnerability, or crash.

This commit simply deletes two helper shell scripts from the contrib/ directory that were used by the project's internal CI tooling. There is no change to the actual Rust Bitcoin library code, no change to how the software behaves at runtime, and no security relevance.

This commit simply deletes two compiled Rust library files (.rlib) that were accidentally added to the repository. There is no code change, no bug fix, and no security issue in the commit itself.

This commit is a routine build-maintenance change. It removes an old shell script used to update dependency lock files and switches the project to using a new internal tool called cargo-rbmt for the same task. There is no change to the actual Bitcoin library code, no security fix, and no vulnerability introduced.

This commit adds a safety limit when reading Bitcoin's 'CompactSize' numbers from serialized data. Before, a malformed message could claim an absurdly large number of elements (for example, billions of items in a list), which could be used to exhaust memory or trigger a panic. Now values above Bitcoin Core's documented maximum are rejected early during parsing. The change also refactors the parsing code so tests can still check non-minimal encoding without the new limit.

This is a tiny code cleanup change in the rust-bitcoin hashes library. It replaces a more verbose way of referring to a constant (<H as HashEngine>::BLOCK_SIZE) with a simpler equivalent (H::BLOCK_SIZE). The behavior of the program is unchanged, and there is no security relevance.

This commit only updates generated API snapshot files (text files listing public Rust traits and functions). It adds entries showing that several types now implement additional formatting traits like Binary, LowerHex, Octal, UpperHex, and Display. There is no actual code change in this commit, and nothing in it fixes or introduces a security problem.

This commit adds new ways to print or display several simple numeric wrapper types in the rust-bitcoin library, such as block heights, amounts, and timestamps. It does not change any security-sensitive logic, parsing, arithmetic, or network behavior. It is a routine API enhancement with no apparent security relevance.

This commit simply renames two Clippy lint settings in the project's configuration file to match updated Clippy lint names. It does not change any executable code, behavior, or security properties of the library.

This commit adds a new way to encode and decode the Bitcoin 'sendcmpct' P2P network message in the rust-bitcoin library. It is a straightforward feature addition that mirrors existing behavior: any non-zero byte is treated as 'true' for the send_compact flag. There is no indication of a security bug being fixed or introduced.

This commit adds new encoding and decoding machinery for a Bitcoin compact-block-relay data structure called HeaderAndShortIds. It preserves an existing safety check that prevents the combined number of short transaction IDs and prefilled transactions from overflowing a 16-bit limit. The change is mostly a refactor to use newer generic encoder traits; it does not appear to introduce a new vulnerability, but the author notes they do not fully understand why the overflow check guarantees safety of individual index differences.

This commit adds standard encoding and decoding machinery for a Bitcoin peer-to-peer message type called BlockTransactions. It does not change behavior, fix a bug, or close a security hole; it is a routine implementation of serialization traits used elsewhere in the crate.

This commit adds new encoding and decoding machinery for a 6-byte transaction identifier (ShortId) used in Bitcoin compact block relay (BIP 152). It is a routine feature addition that wires an existing type into a newer internal encoding framework. There is no indication of a bug, vulnerability, or security fix in the diff or commit message.

This commit adds new encoding/decoding machinery for a Bitcoin P2P data structure called PrefilledTransaction. The main security-relevant detail is that it now explicitly rejects an invalid (too-large) transaction index instead of silently truncating or misinterpreting it. It is a defensive correctness improvement, not a fix for a known exploitable vulnerability.

This is a routine code cleanup that makes the crate's no_std setup consistent with other crates in the same repository. It does not fix a security bug and does not change behavior for users.

This is a routine internal cleanup in the Rust Bitcoin project. It changes how one small crate declares its relationship to the Rust standard library so that it matches the style used by other crates in the same repository. There is no security-relevant change here.

This commit is a simple rename of types and identifiers in the Bitcoin peer-to-peer networking code. It changes names like RawNetworkMessage to V1NetworkMessage to better reflect that they implement the older Bitcoin v1 protocol, now that v2 protocol support exists. No behavior, logic, or security properties of the code are changed.

This commit changes a single timing parameter in the Bitcoin network rules code from a 64-bit integer to a 32-bit integer. The value represents the expected seconds between blocks. The change simplifies the code by removing casts, but it slightly reduces the maximum value that parameter can hold. For all real Bitcoin networks this is harmless because the value is small (600 seconds for Bitcoin mainnet, 120 in the example). There is no direct security fix or vulnerability being patched.

This commit is a routine API cleanup in the rust-bitcoin library. It removes an extra 'parity' argument and return value from functions that tweak public keys for Taproot, because the parity information can now be stored directly inside the XOnlyPublicKey type. There is no indication this fixes a security bug; it is a design simplification that may require downstream code to update how it calls these functions.

This commit is a routine API cleanup, not a security fix. It renames a method from `public_key` to `to_public_key` and removes a now-redundant `parity` argument because the parity information is already stored inside the x-only public key object. The code still produces the same public keys; callers just provide the parity in a different way. There is no indication this change fixes a vulnerability.

This commit is a routine API cleanup in the rust-bitcoin library. It changes a function so it returns only the x-only public key, instead of a pair of the key plus its parity bit. The parity information is now stored inside the key object itself, so callers no longer need to handle it separately. There is no security vulnerability here.

This commit changes the public API of XOnlyPublicKey::serialize() so it now returns both the 32-byte x-only key and its parity bit, instead of just the bytes. All existing callers inside the crate are updated to take only the first element (the bytes) and ignore the parity where it isn't needed. This is a routine API design change to expose extra information for users who need to fully reconstruct a key; it does not fix a bug or close a security hole.

This commit simply renames a function from XOnlyPublicKey::new to XOnlyPublicKey::from_secp because the old name was misleading. The underlying behavior is unchanged. There is no security vulnerability or fix here.

This commit changes how a Bitcoin public-key type is serialized and deserialized when the optional serde feature is enabled. The old code automatically used the inner key type's format, which would break if extra data (such as key parity) is added later. The new code explicitly forwards to the inner type, keeping the wire format stable even as the wrapper type evolves. It is a hardening/preventive change rather than a fix for an active vulnerability.

This is a routine internal code refactor in a Bitcoin cryptography library. It adds a 'parity' field (a mathematical property of cryptographic keys) to the XOnlyPublicKey type, along with getter and setter functions. There is no indication this change fixes or introduces a security vulnerability.