RB
← All projectsRust Bitcoin

rust-bitcoin

Rust library for Bitcoin data structures, serialization, consensus encoding, and scripts.

BitcoinCryptographic librariesNormal
Repository coverage

2289 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

524security candidates506second-pass queue2193AI analyses
148commits · 30 days
304commits · 60 days
1150commits · 180 days
2055commits · 365 days
Backfill bands
Aug 5 → Feb 6787 seen32 candidatesComplete
Feb 6 → Jun 6878 seen53 candidatesComplete
Jun 6 → Jul 6211 seen15 candidatesComplete
Jul 6 → Aug 5184 seen2 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

66/100 average clarity
489Strong · 80–100
1083Adequate · 60–79
566Thin · 40–59
151Opaque · 0–39
20security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Mitchell Bagot649193645068
Andrew Poelstra21072145089
Tobin C. Harding41566410063
jrakibi944994068
Nick Johnson19121190060
Jamil Lambert, PhD11919116061
satsfy (Renato Britto)381527066
Fmt Bot331431045
Trevor Arjeski111111069
Shing Him Ng31731056
Ismail Daif22622050
Martin Habovstiak28527069
Analysis record

Published AI watches

Last scanned 51 minutes ago

Informational 15 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6909: build(deps): bump actions/labeler from 6.2.0 to 7.0.0

This commit updates a GitHub Actions automation tool (actions/labeler) used to automatically tag pull requests with labels. It is a routine dependency version bump from 6.2.0 to 7.0.0, with no indication of a security fix or vulnerability.…

4ed7c068by Andrew Poelstra+1−11 file
No security note in commit
Informational 15 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6910: build(deps): bump actions/checkout from 7.0.0 to 7.0.1

This commit is a routine update to the GitHub Actions checkout tool used by the project's automated workflows. It only changes version numbers in configuration files and does not alter the actual Bitcoin library code that users run. There …

328c4ae9by Andrew Poelstra+37−3717 files
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6911: build(deps): bump astral-sh/setup-uv from 8.3.2 to 9.0.0

This commit updates a GitHub Actions helper used to install a Python tool called uv, which runs the zizmor security scanner. The change only bumps the pinned version of the helper from 8.3.2 to 9.0.0. The new version's release notes mentio…

No security-relevant signals in commit or upstream release notesDependency bump in CI only, not in library codeNo CVE or advisory referenced
67600795by Andrew Poelstra+2−22 files
No security note in commit
Informational 15 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6912: build(deps): bump github/codeql-action/upload-sarif from 4.37.0 to 4.37.3

This is a routine Dependabot update that changes the pinned version of GitHub's official CodeQL upload-sarif action from 4.37.0 to 4.37.3 in a single CI workflow. The action only uploads static analysis results to GitHub; it does not touch…

b51cec63by Andrew Poelstra+1−11 file
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6913: build(deps): bump dtolnay/rust-toolchain from 6c977a6ca4077a0ceb28ffbe03f59d46e9ac8772 to 02cb101ec7c40f2c49e1d9714d64511d8e1b74de

This is a routine update to a GitHub Actions helper used to install Rust during automated testing. It only changes the pinned version of the dtolnay/rust-toolchain action in workflow files. There is no change to the actual rust-bitcoin lib…

90330d15by Andrew Poelstra+8−84 files
No security note in commit
Informational 20 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6906: consensus_encoding, primitives: expose exact encoding size for block and transaction

This commit adds a way to ask, in advance, exactly how many bytes a Bitcoin block or transaction will take when serialized. It is a feature addition for the library's encoding system, not a fix for a vulnerability. There is no indication i…

No security-relevant signals in commit message or diffFeature addition: expose exact encoded sizeNo mention of vulnerability, CVE, bug bounty, or security report
1a365d53by Andrew Poelstra+129−1068 files
No security note in commit
Informational 15 AI analysisMessage 88 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

build(deps): bump dtolnay/rust-toolchain

This is a routine update by Dependabot that changes which version of a popular GitHub Action (dtolnay/rust-toolchain) is used to install Rust in automated CI workflows. The commit only updates pinned commit hashes in workflow files; it doe…

a31e0b0eby dependabot[bot]+8−84 files
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

build(deps): bump github/codeql-action/upload-sarif

This is a routine patch-version update of a GitHub-maintained action used only to upload static-analysis results (SARIF files) from a scheduled CI job. The change does not touch any project source code, cryptographic logic, or user-facing …

2cac6e38by dependabot[bot]+1−11 file
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

build(deps): bump astral-sh/setup-uv from 8.3.2 to 9.0.0

This is a routine automated update by Dependabot that changes the pinned version of a GitHub Action used to install a Python tool called 'uv' in two workflow files. The new version is a major release of the setup-uv action itself, but the …

7d7e7269by dependabot[bot]+2−22 files
No security note in commit
Informational 21 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6894: Harden `Copy` policy and apply to all pre-1.0 crates

This commit removes the automatic `Copy` trait from several public error types in the rust-bitcoin library and updates the project's written policy to discourage `Copy` on error types. `Copy` is a Rust trait that lets values be duplicated …

API hardening: removes `Copy` from public error types to preserve future flexibilityPolicy update: docs/policy.md now explicitly discourages `Copy` on error typesNo vulnerability fix: change is defensive/preventive, not reactive to a disclosed issue
457cb9b5by Andrew Poelstra+14−146 files
No security note in commit
Informational 18 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6787: Move `from_script` to `Address` and drop `AddressExt`

This change is a routine code cleanup, not a security fix. It moves a method that converts Bitcoin output scripts into human-readable addresses from a temporary 'extension trait' directly onto the main Address type. The actual conversion l…

ed42dabdby Andrew Poelstra+38−414 files
No security note in commit
Low 35 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6061: Units improvements

This is a routine code-quality and API-expansion pull request for the rust-bitcoin library's 'units' crate. It widens some fee-rate constructors from 32-bit to 64-bit inputs, renames the old 32-bit versions, improves serde error messages, …

API surface change: new u64 fee-rate constructors return NumOpResult to prevent silent overflowRenaming of existing u32 constructors to *_u32 may break downstream callers at compile time (breaking API change)Removal of artificial restriction in from_per_vb allows larger valid inputs
f9460859by Andrew Poelstra+266−12211 files
No security note in commit
Low 49 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6862: units: Preserve error in NumOpResult add and sub

This commit fixes a bug in how the library handles math errors. Previously, if you added or subtracted two values and one of them already had an error (for example, dividing by zero), the library would silently replace that original error …

Error-state information loss in arithmetic wrapper typeIncorrect error propagation could mask prior failures such as division by zeroDefensive correctness fix in numeric operation result handling
5324e59aby Andrew Poelstra+26−41 file
No security note in commit
Low 37 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6896: Fix `cargo audit` findings

This is a routine dependency-maintenance merge that swaps out old, unmaintained helper libraries for newer, patched versions in the project's example embedded programs and benchmark harness. The changes are driven by automated security sca…

cargo audit advisory remediationdependency upgrade for known-vulnerable crate (rand 0.7 / jobserver)dependency upgrade for known-vulnerable crate (crossbeam-epoch)
5f5f666dby Andrew Poelstra+51−1849 files
Vendor flagged security relevance
Low 37 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6897: consensus_encoding: fix overcounting bug in the composite encoders exact size len calculation

This commit fixes a counting bug in a Rust Bitcoin library. The library has combined encoders that bundle multiple pieces of data together. A method called len() is supposed to report how many bytes are left to encode, but it was incorrect…

Violation of documented API contract (ExactSizeEncoder::len)Potential incorrect buffer-size or progress decisions by downstream callersComposite encoder state not fully isolated in size reporting before fix
22bbc326by Andrew Poelstra+19−13 files
No security note in commit
Low 37 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

consensus_encoding: fix bug in the composite encoder's exact size

This commit fixes a bookkeeping bug in a Rust Bitcoin library's composite encoder. The encoder is a tool that combines multiple pieces of data into a single byte stream, and it has a method that is supposed to report how many bytes are lef…

Incorrect implementation of a documented size/length contractPotential for callers to over-allocate buffers or miscompute transaction/witness sizesComposite encoder used in consensus-critical serialization paths
914365b4by Nick Johnson+19−13 files
No security note in commit
Informational 18 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6809: addresses: Add `AddressParams` type and remove most uses of network types

This is a routine API refactoring in the rust-bitcoin library. It introduces a new AddressParams type and replaces most public uses of the older Network/NetworkKind types when creating or validating Bitcoin addresses. There is no security …

No memory-safety issues, cryptographic errors, or input-validation changes observedNo new unsafe blocks, no new dependencies, no new parsing of untrusted dataAPI surface change only: parameter types replaced with semantically equivalent AddressParams
81032b1aby Andrew Poelstra+208−16414 files
No security note in commit
Low 38 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6886: units: preserve original err summing `NumOpResult`

This patch fixes a bug in how rust-bitcoin adds up a list of numeric operation results. Previously, if any item in the list already carried an error (for example, dividing by zero), the summing code would overwrite that error and falsely r…

Error-type confusion / misattribution in arithmetic result aggregationLoss of original failure context across iterator foldPotential for downstream logic to act on wrong `MathOp`/`MathErrorKind`
4af1ee1dby Andrew Poelstra+23−191 file
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6618: ci: disable fail-fast in weekly rustc update crons

This commit changes two GitHub Actions workflow files used for weekly automated Rust toolchain updates. It adds `fail-fast: false` so that if one branch's update job fails, the other branch jobs continue running instead of all being cancel…

c0a70548by Andrew Poelstra+2−02 files
No security note in commit
Moderate 62 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6884: units: Fix div_by_fee_rate_floor precision

This commit fixes a precision bug in a Rust Bitcoin library function that calculates how much transaction weight a given amount of money can afford at a given fee rate. The old code rounded the fee rate up to a coarser unit (satoshis per k…

Incorrect fee-rate-to-weight conversion leading to understated affordable weightInteger rounding direction (ceil) used as divisor in floor division causing off-by-one or larger precision lossAddition of overflow handling for Weight::MAX
9caad2c1by Andrew Poelstra+23−52 files
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidateAdd {Lower,Upper}Hex to ecdsa::Signatureby Mitchell Bagot · 69540f98 · Jul 1, 2026 · 1 fileMessage 83 · StrongInformational 20Details
Commit message · Mitchell Bagot

Add {Lower,Upper}Hex to ecdsa::Signature

The Taproot Signature type has Debug, Display, LowerHex and UpperHex
impls. The ECDSA signature, by contrast, only has Debug and Display.
Since the Display impl already displays a lowercase hex format,
explicit lower and uppercase hex formatting should be added and the
Display impl modified to call through to LowerHex.

Add LowerHex and UpperHex impls and modify Display to call through to
LowerHex in ecdsa::Signature.
Add tests to verify new behaviour.

83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 20/100

This commit adds new ways to print ECDSA Bitcoin signatures as hexadecimal text (lowercase and uppercase), matching formatting already available for Taproot signatures. It also makes the existing Display implementation reuse the new LowerHex implementation. There is no security fix or behavior change that affects signatures themselves—only how they look when formatted as text.

Security candidateReplace Signature Display with call to SerializedSignatureby Mitchell Bagot · c8ee6361 · Jul 1, 2026 · 1 fileMessage 90 · StrongLow 26Details
Commit message · Mitchell Bagot

Replace Signature Display with call to SerializedSignature

The current ecdsa::Signature Display impl independently calls fmt on
the DER encoded signature, followed by the sighash_type byte. Due to
the handling of format args, this can cause incorrect formatting
handling.

Replace Signature Display impl with a single call-through to Display
on the ecdsa::SerializedSignature.

90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Low 26/100

This commit fixes a formatting bug in how Bitcoin ECDSA signatures are printed as text. Previously, the signature was printed in two separate pieces (the DER-encoded signature and the sighash byte), which could mishandle formatting options like width or precision. Now it prints a single pre-serialized object, so formatting behaves consistently. This is a correctness bug, not a cryptographic vulnerability, and there is no evidence it enables code execution or theft of funds.

Security candidateAdd PartialOrd, Ord to ecdsa::Signatureby Mitchell Bagot · 1e020732 · Jul 1, 2026 · 2 filesMessage 73 · AdequateInformational 16Details
Commit message · Mitchell Bagot

Add PartialOrd, Ord to ecdsa::Signature

The Taproot signature has a PartialOrd & Ord derive. So too, do both
the ecdsa and schnorr signatures in secp256k1. Thus, it stands to
reason that the ECDSA signature type should also.

Add PartialOrd and Ord to EcdsaSighashType and ecdsa::Signature.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 16/100

This commit simply adds standard sorting traits (PartialOrd and Ord) to an ECDSA signature type and its associated sighash type, matching what already exists for similar types. There is no indication this fixes or introduces a security problem.

Security candidateRemove PrivateKeyExt and make PrivateKey::as_inner privateby Mitchell Bagot · e9ea66a1 · Jul 1, 2026 · 4 filesMessage 73 · AdequateInformational 19Details
Commit message · Mitchell Bagot

Remove PrivateKeyExt and make PrivateKey::as_inner private

The raw_ecdsa_sign_recoverable function on PrivateKeyExt is intended to
provide a cleaner interface for working with recoverable signatures.
However, this function requires the presence of an extension trait and
blocks the hiding of the PrivateKey::as_inner function. Since
sign_message is considered unofficially deprecated anyway, it's better
to make its API messy in the pursuit of a cleaner key API.

Remove PrivateKeyExt trait and make PrivateKey::as_inner private.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarycryptography-sensitive pathsigning or wallet path
AI analysis · Informational 19/100

This commit is a routine API cleanup, not a security fix. It removes a helper trait called PrivateKeyExt and hides a low-level accessor method (as_inner) that exposes the underlying secret key object. The same signing behavior is preserved inside the crate, just with less public surface area. There is no patch for an active vulnerability.

Security candidaterefactor: remove DerivationErrorby Trevor Arjeski · 72954d3a · Jun 30, 2026 · 1 fileMessage 47 · ThinInformational 19Details
Commit message · Trevor Arjeski

refactor: remove DerivationError

47/100 · ThinMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 19/100

This commit removes a deprecated type alias named `DerivationError` from the public API, replacing it with the already-existing `DeriveXpubError`. It is a straightforward cleanup with no functional code changes and no security implications.

Security candidatestyle: reorder bip32 error implsby Trevor Arjeski · 78a3ac3f · Jun 30, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Trevor Arjeski

style: reorder bip32 error impls

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 15/100

This commit is a pure code-style change. It reorders the implementation blocks for several error types in a Bitcoin-related Rust library so that the order of traits (From, std::error::Error, Display, helper methods) is consistent. No logic, behavior, or security properties of the code are changed.

Security candidaterefactor: split bip32 xkey parse errorsby Trevor Arjeski · 55ef86a2 · Jun 30, 2026 · 1 fileMessage 57 · ThinInformational 18Details
Commit message · Trevor Arjeski

refactor: split bip32 xkey parse errors

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 18/100

This commit is a code cleanup: it splits one big error type into several smaller, more specific error types for BIP-32 extended key parsing. It does not change what the code accepts or rejects, only how errors are named and organized. There is no security fix here.

Security candidateRemove Encodable and Decodable impls for crate typesby Mitchell Bagot · 6f136cdf · Jun 30, 2026 · 12 filesMessage 73 · AdequateInformational 11Details
Commit message · Mitchell Bagot

Remove Encodable and Decodable impls for crate types

As a first step for removing the old consensus code, the Encodable
and Decodable impls for all crate types can be removed.

Remove Encodable and Decodable impls for all types from bitcoin,
explicitly leaving core/stdlib types untouched.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 11/100

This commit removes old serialization/deserialization trait implementations (called Encodable and Decodable) from many Bitcoin data types in the rust-bitcoin library. It is described by the project as a cleanup step toward replacing the old consensus encoding code. There is no indication in the commit or supplied references that this fixes a security vulnerability; it appears to be a routine internal refactor.

Security candidateReplace use of con_serde in sighash testby Mitchell Bagot · 09d0c9df · Jun 29, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Replace use of con_serde in sighash test

The bip_341_sighash_tests test in sighash relies on con_serde to hex
decode a transaction in the test data. Since we want to remove old
consensus logic, con_serde will not be available. As such, this test
should be modified to use consensus_encoding's decode_from_hex.

Add hex feature to consensus_encoding dependency in bitcoin.
Replace use of con_serde in bip_341_sighash_tests test with
decode_from_hex.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine internal test refactor. It swaps one test-only helper for another so that a unit test can still decode hex transaction data after an older helper is removed. There is no change to production code or to how real transactions are handled.

Security candidateReplace uses of consensus in testsby Mitchell Bagot · 171f6661 · Jun 29, 2026 · 7 filesMessage 78 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Replace uses of consensus in tests

As with the uses of consensus::encode in the main code, the uses in the
tests and doctest examples can also be replaced.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

This commit only changes test code and documentation examples in the rust-bitcoin library. It replaces older consensus encoding/decoding helper functions with newer equivalents from a different internal module. There is no change to production code, no bug fix, and no security-relevant behavior change.

Security candidateReplace uses of bitcoin::consensus with consensus_encodingby Mitchell Bagot · 22cf8fb6 · Jun 29, 2026 · 6 filesMessage 73 · AdequateLow 33Details
Commit message · Mitchell Bagot

Replace uses of bitcoin::consensus with consensus_encoding

Throughout the bitcoin code, there are various uses of the old encoding
traits used to implement functionality. With the introduction of the
new encoding and decoding implementations, all of these can be replaced
with the new implementations to remove the dependency on bitcoin.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Low 33/100

This commit swaps out an older Bitcoin data-encoding system for a newer one across six files. It is a routine internal refactoring change. There is no direct evidence in the commit that it fixes a security vulnerability, but any encoding change in consensus-critical code carries a small risk that a subtle behavior difference could affect transaction or block validation. The commit message and diff do not describe any security issue or credit a researcher.

Security candidateAdd XOnlyPublicKey::verifyby Mitchell Bagot · 8a5deee2 · Jun 29, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Mitchell Bagot

Add XOnlyPublicKey::verify

At present, users who wish to verify a message with a Schnorr signature
need to use the secp256k1 library directly. Since Legacy/FullPublicKey
already provide verify functions for ECDSA, XOnlyPublicKey should
provide a similar function for Schnorr.

Add XOnlyPublicKey::verify to Schnorr verify messages with a
taproot::Signature.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 18/100

This commit adds a new convenience method, XOnlyPublicKey::verify, that lets users verify Schnorr (taproot) signatures without calling the underlying secp256k1 library directly. It is a straightforward API addition with no obvious security bug; it simply wraps the existing, well-tested secp256k1 Schnorr verification routine.

Security candidateMove TapTweak trait to taproot-primitivesby Mitchell Bagot · 6912358e · Jun 29, 2026 · 2 filesMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Move TapTweak trait to taproot-primitives

The TapTweak trait is necessary for WitnessProgram::p2tr and thus
Address::p2tr. With from_key_and_merkle_root moved back to
taproot-primitives, this trait can now be moved alongside it and
and later used in addresses.

Move TapTweak trait to taproot-primitives.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine code reorganization. It moves the TapTweak trait and its implementations from the main bitcoin crate into a smaller taproot-primitives crate. The actual logic for tweaking Taproot keys is copied unchanged; only its location in the codebase changes. There is no security bug being fixed or introduced.

Security candidateReplace dyn fmt::Write with fmt::Formatterby Mitchell Bagot · 22da6c4f · Jun 26, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Replace dyn fmt::Write with fmt::Formatter

In Rust, the dyn keyword for a function parameter provides generic-like
functionality for a parameter. However, unlike impl or a generic, dyn
enables dynamic dispatch for the function, preventing inlining by the
compiler. Since all such uses of dyn fmt::Write are used with formatter
anyway, the dynamic dispatch cost can be eliminated by replacing the
dyn param with a fmt::Formatter type.

Replace dyn fmt::Write with fmt::Formatter in all non-deprecated
functions.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine performance and code-quality refactor. It replaces dynamically-dispatched formatter parameters with concrete Rust formatter types so the compiler can inline the code. There is no security-relevant change: no new inputs are accepted, no validation logic changes, and no sensitive data handling is altered.

Security candidateAdd tests to verify 0 return for overflowby Mitchell Bagot · 4ee43312 · Jun 24, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · Mitchell Bagot

Add tests to verify 0 return for overflow

Following the previous change to Target::from_compact, the tests should
be updated to confirm the 0 for overflow, and also to check the
boundary values for the overflow.

Add and adjust pow unit tests to check the overflow logic if
Target::from_compact.

83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 12/100

This commit only adds new unit tests to verify that a previously changed function, Target::from_compact, returns zero when a Bitcoin 'compact' difficulty value overflows a 256-bit target. It does not change any production code. The tests confirm the overflow behavior and check values right at the overflow boundary.

Security candidateReturn 0 on Target::from_compact overflowby Mitchell Bagot · 1fb9a651 · Jun 24, 2026 · 1 fileMessage 73 · AdequateModerate 59Details
Commit message · Mitchell Bagot

Return 0 on Target::from_compact overflow

Currently, the Target::from_compact function treats a negative mantissa
as a failure mode and returns a Target value of zero. This lines up
with Core's SetCompact, which sets a pfNegative flag in the same case.
In Core, a pfOverflow flag is similarly set in overflow cases, and in
every case where a negative flag is treated as a failure, the overflow
is too. As such, our implementation should also return Target::ZERO in
the overflow case as it does for the negative case.

Return Target::ZERO for mantissa/exponent values which overflow in
Target::from_compact.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Moderate 59/100

This commit fixes a bug in how rust-bitcoin converts Bitcoin 'compact' difficulty targets into full numeric Target values. Previously, if the compact value encoded a number too large to fit in a valid Target, the code would silently produce a truncated/wrapped result instead of treating it as invalid. The fix makes overflow behave like an invalid negative mantissa: return zero. This aligns the library with Bitcoin Core's consensus behavior, reducing the risk of consensus divergence or incorrect difficulty calculations.

Security candidateClear pushnum cache on signature operations in sigop countby Abeeujah · 7c8db561 · Jun 23, 2026 · 2 filesMessage 78 · AdequateModerate 60Details
Commit message · Abeeujah

Clear pushnum cache on signature operations in sigop count

The `pushnum_cache` was not cleared when encountering a non-push
signature opcode like `OP_CHECKSIG`. This allowed stale push numbers
to leak into subsequent multisig operations if they weren't directly
preceded by a small int push.

Fix this by resetting the cache on signature opcodes, aligning the
sigop calculation with Bitcoin Core consensus logic.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Moderate 60/100

This commit fixes a bug in how the library counts 'signature operations' (sigops) in Bitcoin scripts. A small cache that remembers recently pushed numbers was not being cleared after signature-checking opcodes. This could cause a later multi-signature operation to incorrectly reuse a stale number, making the sigop count too low or too high in edge cases. The fix resets the cache whenever a signature opcode is seen, matching Bitcoin Core's consensus behavior.

Security candidateMove from_key_and_merkle_root back to taproot-primitivesby Mitchell Bagot · 4e5407b4 · Jun 23, 2026 · 6 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Move from_key_and_merkle_root back to taproot-primitives

Contrary to the prior reasoning, this function is necessary for
TapTweak to be moved to taproot-primitives. Since TapTweak needs to
move to taproot-primitives for the sake of addresses, this will need
to be moved back to taproot-primitives.

Remove TapTweakHashExt and move from_key_and_merkle_root back to the
base type in taproot-primitives.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine internal code reorganization. It moves a helper function that computes a Taproot tweak hash from one module to another and removes an extension trait that was only used to attach that function. There is no security fix or behavior change visible in the diff.

Security candidaterefactor: split bip32 path parse errorsby Trevor Arjeski · 22a4cbc6 · Jun 23, 2026 · 1 fileMessage 57 · ThinInformational 18Details
Commit message · Trevor Arjeski

refactor: split bip32 path parse errors

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 18/100

This commit is a code cleanup (refactor) that splits one combined error type into two separate error types for parsing BIP32 derivation paths. It does not change the actual parsing rules or fix any security bug. It only changes how error messages are categorized internally, making the API clearer for developers. There is no indication this addresses a vulnerability.

Security candidaterefactor: split bip32 derivation errorsby Trevor Arjeski · f83c5dd2 · Jun 23, 2026 · 1 fileMessage 57 · ThinInformational 17Details
Commit message · Trevor Arjeski

refactor: split bip32 derivation errors

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 17/100

This commit is a code cleanup in the rust-bitcoin library. It splits one general BIP32 derivation error type into several more specific error types and renames the old one. It does not change how keys are actually derived or add any new security behavior; it only changes how error conditions are named and reported to programmers.

Security candidateReplace impl_to_hex_from_lower_hex with deprecated inherent to_hexby Mitchell Bagot · a88ecdfa · Jun 23, 2026 · 6 filesMessage 73 · AdequateInformational 18Details
Commit message · Mitchell Bagot

Replace impl_to_hex_from_lower_hex with deprecated inherent to_hex

The impl_to_hex_from_lower_hex macro from internals implements a to_hex
function for a type by calling through to an existing LowerHex impl.
This has been something that we've wanted to remove for a while, so
a first step involves deprecating the macro and removing all uses.

Replace impl_to_hex_from_lower_hex with deprecated inherent to_hex on
all types.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 18/100

This is a routine code cleanup change. It replaces an internal helper macro that generated `to_hex` methods with manually-written, equivalent `to_hex` methods that are marked as deprecated. The public API behavior stays the same; callers will just receive a deprecation warning encouraging them to use Rust's standard `format!("{var:x}")` instead. There is no security fix or vulnerability here.

Security candidateMove impl_array_newtype to include/array_newtype.rsby Mitchell Bagot · 177d87b8 · Jun 23, 2026 · 9 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Move impl_array_newtype to include/array_newtype.rs

The array_newtype.rs include file has been used for bitcoin's
previously internal macro impl_array_newtype_stringify. Since the name
lends itself to dual usage with the impl_array_newtype macro, and the
two may be used together, the macro can be copied from internals to
this include file.

Move impl_array_newtype macro to include/array_newtype.rs. Deprecate in
internals and replace uses with include! copy.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine code reorganization. It moves a Rust macro called impl_array_newtype from one internal location to a shared include file and updates call sites to use the new location. No behavior changes, bug fixes, or security fixes are visible in the diff.

Security candidateAdd regression test for from_base64 bugby Mitchell Bagot · 188f9f30 · Jun 17, 2026 · 1 fileMessage 90 · StrongInformational 12Details
Commit message · Mitchell Bagot

Add regression test for from_base64 bug

To prevent changes to the from_base64 function reintroducing the non-65
byte invalid behaviour, a regression test should be added to catch any
changes.

Introduce regression test for
sign_message::MessageSignature::from_base64.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundaryfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new regression test. It does not change any production code. The test checks that a function called from_base64 correctly rejects base64 inputs that decode to fewer or more than 65 bytes. Because no actual fix is included in this commit, the commit itself does not introduce or remove a security vulnerability; it merely adds a test to help catch the bug in the future.

Security candidateUse write! in UnknownAddressTypeError displayby Mitchell Bagot · 5d63ec21 · Jun 16, 2026 · 1 fileMessage 73 · AdequateLow 35Details
Commit message · Mitchell Bagot

Use write! in UnknownAddressTypeError display

The write_err! macro is intended to provide source information for
errors in no_std environments. Where an error type does not have a
source, the write! macro should be used instead.
For UnknownAddressTypeError specifically, the use of write_err! causes
a stack overflow as it recurses infinitely to attempt to display self
as the source in write_err! in no_std builds.

Replace use of write_err! with write! in UnknownAddressTypeError
Display impl.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 35/100

This commit fixes a bug where displaying a specific error message in Bitcoin address parsing could cause the program to crash with a stack overflow. The crash only happens in 'no_std' builds (a special configuration without the standard library). The fix replaces an incorrect macro with the correct one so the error message is shown without trying to endlessly include itself as its own source.

Security candidate2026-06-14 automated rustfmt nightlyby Fmt Bot · 90c665e3 · Jun 14, 2026 · 2 filesMessage 45 · ThinInformational 15Details
Commit message · Fmt Bot

2026-06-14 automated rustfmt nightly

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathparser or protocol path
AI analysis · Informational 15/100

This commit is an automated code-formatting run by rustfmt. It only reorders import/use statements in two files without changing any program logic, behavior, or security properties.