RB
← All projectsRust Bitcoin

rust-bitcoin

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

BitcoinCryptographic librariesNormal
Repository coverage

2070 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.

459security candidates448second-pass queue202AI analyses
194commits · 30 days
405commits · 60 days
1283commits · 180 days
2070commits · 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.

64/100 average clarity
311Strong · 80–100
1054Adequate · 60–79
555Thin · 40–59
150Opaque · 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 Bagot64019290068
Tobin C. Harding4096528063
jrakibi944910068
Nick Johnson189203059
Andrew Poelstra51209075
Jamil Lambert, PhD114184061
Fmt Bot311411045
Trevor Arjeski111110069
Shing Him Ng3174056
Ismail Daif2263050
satsfy (Renato Britto)1766066
Martin Habovstiak2754069
Analysis record

Published AI watches

Last scanned 44 minutes ago

Informational 17 AI analysisMessage 80 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

refactor(bip32): Xpub child tweak api

This commit is a straightforward API refactor in the BIP-32 (Bitcoin key derivation) code. It replaces a function that returned a raw secret key and chain code with one that returns a new structured type called XpubChildTweak. The actual c…

No security-relevant behavioral change observedAPI rename and return-type encapsulation onlyNo new validation, bounds checking, or constant-time guarantees added
37191717by Trevor Arjeski+21−71 file
No security note in commit
Informational 18 AI analysisMessage 85 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

refactor(bip32): rename Xpub and Xpriv derivation methods

This is a routine code cleanup in a Bitcoin library. It renames key-derivation methods on extended public and private keys (Xpub/Xpriv) to clearer names and removes old aliases. There is no security bug being fixed and no new vulnerability…

No security-relevant logic changePure API renaming/refactoringDeprecated method removal may break downstream callers at compile time
f8f053fdby Trevor Arjeski+61−852 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add try_push to Buffer trait

This commit adds a new `try_push` method to an internal `Buffer` trait used during Base58 encoding. It is a straightforward, additive change that lets encoding code gracefully handle a full fixed-size buffer in no-allocation builds. There …

aafb6065by Mitchell Bagot+15−01 file
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

consensus_encoding: Rename _with decoder functions

This commit is a simple renaming of internal Rust functions from names ending in '_with' to names ending in '_with_decoder'. It does not change what the code does, only what the functions are called, to avoid confusion with another functio…

12325a67by Mitchell Bagot+18−174 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

2026-07-05 automated rustfmt nightly

This commit is a routine automated code-formatting run by the rustfmt tool. It only changes whitespace, import order, and line breaks in five files. There are no functional changes, no bug fixes, and no security-related modifications.

673e5ee4by Fmt Bot+12−115 files
No security note in commit
Informational 15 AI analysisMessage 95 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

ci: adapt default and no feature bip32 test for rbmt 0.4.0

This is a routine update to the project's automated testing configuration. A tool used to run example tests changed its syntax, so the developer updated one line to keep the same tests running the same way. There is no user-facing change a…

5f933d5cby satsfy (Renato Britto)+1−11 file
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add From/TryFrom for Signature/SerializedSignature

This commit adds standard Rust conversion traits (From/TryFrom) between an ECDSA signature and its serialized byte form. It is a small API-consistency change that mirrors traits already present on the Taproot signature type. There is no in…

No security-relevant keywords in commit title or messageNo changes to cryptographic validation or parsing logicOnly adds convenience trait implementations delegating to existing methods
3cf8c405by Mitchell Bagot+21−01 file
No security note in commit
Informational 20 AI analysisMessage 83 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

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

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 LowerH…

69540f98by Mitchell Bagot+43−51 file
No security note in commit
Low 26 AI analysisMessage 90 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Replace Signature Display with call to SerializedSignature

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…

Incorrect format-flag handling in Display implBehavioral inconsistency between Signature::fmt and SerializedSignature::fmtRegression test added for format-string parity
c8ee6361by Mitchell Bagot+18−21 file
No security note in commit
Informational 16 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add PartialOrd, Ord to ecdsa::Signature

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 pro…

1e020732by Mitchell Bagot+2−22 files
No security note in commit
Informational 19 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Remove PrivateKeyExt and make PrivateKey::as_inner private

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…

Reduction of public API surface for secret-key materialRemoval of extension trait that exposed raw ECDSA recoverable signingas_inner accessor narrowed from pub to pub(super)
e9ea66a1by Mitchell Bagot+14−344 files
No security note in commit
Informational 18 AI analysisMessage 57 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

refactor: split bip32 xkey parse errors

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. Ther…

55ef86a2by Trevor Arjeski+214−771 file
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

style: reorder bip32 error impls

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…

78a3ac3fby Trevor Arjeski+38−381 file
No security note in commit
Informational 11 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Remove Encodable and Decodable impls for crate types

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 ol…

Large deletion of serialization code (535 lines removed)Removal of consensus encoding traits from core Bitcoin typesRemoval of transaction deserialization tests including extreme-size witness/scriptSig tests
6f136cdfby Mitchell Bagot+8−53512 files
No security note in commit
Low 33 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Replace uses of bitcoin::consensus with consensus_encoding

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 c…

Refactor of consensus-critical serialization code (sighash, taproot leaf hash, BIP-158 filters, consensus validation)Change of compact-size encoder/decoder implementation and error typesRemoval of `bitcoin::consensus` dependency from several modules
22cf8fb6by Mitchell Bagot+38−356 files
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Replace uses of consensus in tests

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 produc…

171f6661by Mitchell Bagot+81−697 files
No security note in commit
Informational 18 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add XOnlyPublicKey::verify

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…

New public API surface for signature verificationWraps secp256k1::schnorr::verify without altering verification semanticsNo input parsing, no secret-key handling, no allocator changes
8a5deee2by Mitchell Bagot+28−11 file
No security note in commit
Informational 12 AI analysisMessage 83 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add tests to verify 0 return for overflow

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 c…

4ee43312by Mitchell Bagot+17−01 file
No security note in commit
Moderate 59 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Return 0 on Target::from_compact overflow

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 produc…

Consensus-critical code path modifiedOverflow/wraparound in cryptographic/numeric conversionAlignment with Bitcoin Core behavior (SetCompact overflow flag)
1fb9a651by Mitchell Bagot+7−31 file
No security note in commit
Informational 18 AI analysisMessage 57 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

refactor: split bip32 path parse errors

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 m…

22a4cbc6by Trevor Arjeski+68−291 file
No security note in commit
Repository ledger

Explore captured commits

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

Security candidatebuild(deps): bump actions/checkout from 5.0.0 to 6.0.2by dependabot[bot] · 14a75c38 · Jul 6, 2026 · 16 filesMessage 93 · StrongTriage 0Details
Commit message · dependabot[bot]

build(deps): bump actions/checkout from 5.0.0 to 6.0.2

Bumps [actions/checkout](https://github.com/actions/checkout) from 5.0.0 to 6.0.2.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/08c6903cd8c0fde910a37f88322edcfb5dd907a8...de0fac2e4500dabe0009e67214ff5f5447ce83dd)

---
updated-dependencies:
- dependency-name: actions/checkout
dependency-version: 6.0.2
dependency-type: direct:production
update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
boot or update pathdocumentation-only discountautomated dependency-update discount
Security candidateconsensus_encoding: Rename _with decoder functionsby Mitchell Bagot · 12325a67 · Jul 6, 2026 · 4 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

consensus_encoding: Rename _with decoder functions

The _with decoder functions are generic on Decoder instead of Decode,
which allows them to decode ad-hoc decoder types, rather than requiring
a type with Decode. However, the _with suffix is already used for
decode_from_read_unbuffered_with, in which it has a different meaning.
For the sake of consistency, the _with function suffix should instead
be with_decoder.

Rename _with decoder functions to use _with_decoder suffix instead.

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

This commit is a simple renaming of internal Rust functions from names ending in '_with' to names ending in '_with_decoder'. It does not change what the code does, only what the functions are called, to avoid confusion with another function that already uses '_with' differently. There is no security issue here.

Security candidateMove ScriptPubKeyBufExt to addressesby Mitchell Bagot · ed00d91a · Jul 6, 2026 · 2 filesMessage 63 · AdequateTriage 18Details
Commit message · Mitchell Bagot

Move ScriptPubKeyBufExt to addresses

The new_p2pkh function is necessary to implement the script_pubkey
function on Address. Since the function signature includes a hash type
from crypto, it can't be moved to primitives yet. Instead, we can move
the extension trait to addresses where it can be used, and re-export
the trait in bitcoin to retain the same API.

Move ScriptPubKeyBufExt to addresses, Adjust new_p2pk function impl to
remove use of Builder::push_key.

63/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
Security candidatehashes: Deprecate sha256t_tag macroby jrakibi · ac921e97 · Jul 5, 2026 · 3 filesMessage 50 · ThinTriage 15Details
Commit message · jrakibi

hashes: Deprecate sha256t_tag macro

Deprecate the macro in favor of implementing sha256t::Tag by hand

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
cryptography-sensitive path
Security candidate2026-07-05 automated rustfmt nightlyby Fmt Bot · 673e5ee4 · Jul 5, 2026 · 5 filesMessage 45 · ThinInformational 15Details
Commit message · Fmt Bot

2026-07-05 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 pathsigning or wallet path
AI analysis · Informational 15/100

This commit is a routine automated code-formatting run by the rustfmt tool. It only changes whitespace, import order, and line breaks in five files. There are no functional changes, no bug fixes, and no security-related modifications.

Security candidatehashes: implement sha256t::Tag without the macroby jrakibi · 0131814d · Jul 4, 2026 · 3 filesMessage 68 · AdequateTriage 15Details
Commit message · jrakibi

hashes: implement sha256t::Tag without the macro

Midstate::hash_tag is a const fn, so a tag can be defined by hand with
a sha256t::Tag impl without using the macro. The macro dates to a time
before sha256 could be computed in a const context (constfns make it
unnecessary now)

Migrate the tag definitions off the macro:
- taproot-primitives: TapLeafTag, TapBranchTag, TapTweakTag
- bitcoin: TapSighashTag

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
Security candidateci: adapt default and no feature bip32 test for rbmt 0.4.0by satsfy (Renato Britto) · 5f933d5c · Jul 3, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · satsfy (Renato Britto)

ci: adapt default and no feature bip32 test for rbmt 0.4.0

Rbmt 0.4.0 changes how the example test matrix parses feature specs. The
sentinel for no default features was removed (bare name now means no default
features). The config relied on the old meaning that bip32 ran with default
features and 'bip32:-' ran with no features.

Translate both to the new syntax so the same two runs are preserved: 'bip32'
(no features) and 'bip32:std secp-recovery' (default feature set).

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
secret or key material
AI analysis · Informational 15/100

This is a routine update to the project's automated testing configuration. A tool used to run example tests changed its syntax, so the developer updated one line to keep the same tests running the same way. There is no user-facing change and no security relevance.

Security candidateReplace uses of encode_to_engine with encode_to_hashby Mitchell Bagot · f40e1879 · Jul 2, 2026 · 2 filesMessage 73 · AdequateTriage 15Details
Commit message · Mitchell Bagot

Replace uses of encode_to_engine with encode_to_hash

There are a couple of uses of encode_to_engine that follow the trivial
pattern and can be replaced with encode_to_hash.

Replace appropriate uses of encode_to_engine in sighash and primitives
with encode_to_hash to simplify the code.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
Security candidateExtend update toolchains to LTS branchesby Nick Johnson · 11f42a41 · Jul 1, 2026 · 2 filesMessage 45 · ThinTriage 0Details
Commit message · Nick Johnson

Extend update toolchains to LTS branches

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
boot or update pathdocumentation-only discount
Security candidateAdd From/TryFrom for Signature/SerializedSignatureby Mitchell Bagot · 3cf8c405 · Jul 1, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Add From/TryFrom for Signature/SerializedSignature

These impls exist on the Taproot Signature type, but not on the ECDSA
Signature. For consistency, they should.

Add From and TryFrom impls for conversions between Signature and
SerializedSignature.

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 boundarycryptography-sensitive path
AI analysis · Informational 15/100

This commit adds standard Rust conversion traits (From/TryFrom) between an ECDSA signature and its serialized byte form. It is a small API-consistency change that mirrors traits already present on the Taproot signature type. There is no indication it fixes a security bug or introduces a vulnerability.

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 · ThinTriage 15Details
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
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 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 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 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 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 use of con_serde in sighash testby Mitchell Bagot · 09d0c9df · Jun 29, 2026 · 2 filesMessage 78 · AdequateTriage 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
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 · AdequateTriage 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
Security candidateReplace dyn fmt::Write with fmt::Formatterby Mitchell Bagot · 22da6c4f · Jun 26, 2026 · 3 filesMessage 68 · AdequateTriage 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
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.