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 queue563AI analyses
190commits · 30 days
404commits · 60 days
1283commits · 180 days
2069commits · 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 Bagot640192232068
Tobin C. Harding4096580063
jrakibi944954068
Nick Johnson1892027059
Andrew Poelstra512020075
Jamil Lambert, PhD1141830061
Fmt Bot311416045
Trevor Arjeski111111069
Shing Him Ng31710056
Ismail Daif2267050
satsfy (Renato Britto)1768066
Martin Habovstiak2759069
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#6670: ci: fix labeller permissions

This is a routine GitHub Actions workflow fix. The change gives the automated PR labeler workflow permission to download artifacts and explicitly tells the GitHub CLI which repository to act on. It does not change the Bitcoin library code,…

CI workflow permission fixNo source code changesNo cryptographic or consensus changes
276e0a61by Andrew Poelstra+5−01 file
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6657: Release tracking PR: `base58ck 0.5.0`

This commit is a routine version bump for the base58ck crate from 0.4.0 to 0.5.0. It only updates version numbers in package manifests, lock files, and adds a changelog entry. There are no code changes and no security relevance.

9deb5de1by Andrew Poelstra+22−168 files
No security note in commit
Informational 21 AI analysisMessage 100 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6440: base58: Introduce `decode_check_to_array` for alloc-less decoding

This commit is a routine feature addition to the rust-bitcoin base58 crate. It adds a new no-allocator function to decode short base58-check strings into fixed-size byte arrays, and renames the existing error type while keeping a deprecate…

No security-relevant bug fix is described in the commit message or diff.New decoding path uses a fixed 128-byte scratch buffer (`ArrayVec`) and rejects oversized inputs.Checksum verification and invalid-character handling are preserved from the existing alloc implementation.
c5fd1832by Andrew Poelstra+330−775 files
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6646: hashes: add several methods to `Midstate` and release 1.2.0

This commit is a routine feature release for the bitcoin_hashes crate. It adds new public methods and a constant to the SHA-256 Midstate type so developers can compute SHA-256 midstates in const contexts. There is no indication of a securi…

0f68fcb3by Andrew Poelstra+157−4210 files
No security note in commit
Informational 12 AI analysisMessage 75 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

ci: fix labeller permissions

This commit adjusts a GitHub Actions workflow that automatically labels pull requests based on CI results. It adds a built-in repository token, tells the artifact download step to merge single-file artifacts, and explicitly sets the reposi…

Workflow-only change with no library code modificationsUses the default GITHUB_TOKEN rather than a custom secretRuns in workflow_run context, which already has elevated repository access by design
715f2bd6by Nick Johnson+5−01 file
No security note in commit
Informational 18 AI analysisMessage 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6662: build(deps): bump actions/checkout from 6.0.2 to 6.0.3

This commit is a routine update to the GitHub Actions checkout tool used by the project's automated workflows. It changes the pinned version from 6.0.2 to 6.0.3 across many workflow files. The newer version fixes minor bugs related to SHA-…

Dependency bump of actions/checkout to a patch releaseUpstream fixes for SHA-256 repository checkout and merge commit regexAll affected workflows already disable persisted credentials
f7d364cdby Andrew Poelstra+29−2915 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Scrub the transaction encoding logic

This commit is a pure code reorganization: it moves existing transaction encoding and decoding definitions around within a single file so they follow the project's preferred layout. No logic was changed, no security bug was fixed, and no n…

80dcef15by Tobin C. Harding+57−571 file
No security note in commit
Informational 15 AI analysisMessage 58 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Make the WitnessesEncoder private

This commit simply hides an internal helper type called WitnessesEncoder from public view. It is a routine API-cleanup change with no security relevance visible in the code or commit message.

b37accc3by Tobin C. Harding+54−542 files
No security note in commit
Informational 15 AI analysisMessage 93 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

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

This is a routine automated update by Dependabot that bumps the GitHub Actions 'actions/checkout' dependency from version 6.0.2 to 6.0.3 across all project workflow files. It only changes pinned commit hashes and version comments for the a…

Routine patch-level dependency bumpNo changes to permissions, inputs, or workflow logicpersist-credentials: false already present on all checkout steps
ae935fadby dependabot[bot]+29−2915 files
No security note in commit
Informational 15 AI analysisMessage 60 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

base58ck: Bump version to 0.5.0

This commit is a routine version bump for the base58ck crate from 0.4.0 to 0.5.0. It only updates version numbers in package manifests, lock files, and adds a changelog entry describing unrelated feature changes. There are no code changes,…

8479b56eby Tobin C. Harding+22−168 files
No security note in commit
Informational 20 AI analysisMessage 58 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Rename Error to DecodeCheckError

This commit is a routine code cleanup: it renames the `Error` type in the base58 module to the more descriptive `DecodeCheckError`, and adds a deprecated type alias so existing code using `base58::Error` continues to work. There is no chan…

b0eba4c0by Mitchell Bagot+45−395 files
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: add sha256::Midstate::SHA256_IV constant

This commit is a routine internal refactoring in the rust-bitcoin SHA-256 hashing code. It exposes the SHA-256 initial value (IV) as a public constant and renames an internal helper function so it can start from any midstate rather than al…

dc21841bby Andrew Poelstra+39−143 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: add several methods to sha256::Midstate for computing them in const contexts

This commit adds new helper methods to the SHA-256 'Midstate' type in the rust-bitcoin hashes library. These helpers let callers compute SHA-256 intermediate states inside 'const' contexts (compile-time constants). It is a routine feature …

7d8f06d2by Andrew Poelstra+80−72 files
No security note in commit
Informational 20 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

units: make Sequence inner field private

This commit makes a single internal number field private in a Rust Bitcoin library type called Sequence. It is an API-cleanup change to follow Rust naming conventions (C-STRUCT-PRIVATE). It does not fix a memory corruption bug, a cryptogra…

No security signal: this is an API-encapsulation refactorNo validation or serialization logic changedNo unsafe code, no cryptographic operations modified
30f280daby satsfy (Renato Britto)+9−96 files
No security note in commit
Informational 17 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

taproot-primitives: Implement encoding traits for TapLeafHash

This commit adds standard data-encoding support for a Bitcoin Taproot hash type (TapLeafHash) so it can be properly serialized and deserialized in PSBT data. There is no indication of a security bug being fixed; it appears to be a missing-…

No security-relevant signal in commit message or diffChange is a feature addition (encoding trait implementations)No bounds-checking, memory-safety, or cryptographic flaws evident in diff
b2ab0896by Mitchell Bagot+59−12 files
No security note in commit
Informational 18 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Split Address into an extension trait

This commit is a routine code reorganization in the rust-bitcoin library. It moves the `Address::from_script` method out of the main `Address` type into a new 'extension trait' called `AddressExt`. The actual logic of the function is copie…

c900fa8cby Mitchell Bagot+35−263 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

ci: update cargo-rbmt ever month instead of week

This commit simply renames a GitHub Actions workflow file and changes its schedule from weekly to monthly. It is a routine CI maintenance change with no security relevance.

778018e1by Nick Johnson+46−461 file
No security note in commit
Informational 18 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Use generic arguments for functions

This commit is a routine API cleanup: it makes a few Bitcoin merkle-root functions accept a broader range of input types (generic iterators and borrowed transactions) instead of only slices or exact iterator types. There is no security bug…

e887140aby Mitchell Bagot+26−184 files
No security note in commit
Informational 19 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

units: Flatten nested checked_ops methods

This commit is a straightforward code cleanup in the rust-bitcoin library. It replaces deeply nested match blocks with newer, cleaner Rust syntax (let-else statements) inside safe arithmetic helper functions. The actual behavior of the cod…

99f3721dby Abeeujah+53−1274 files
No security note in commit
Informational 15 AI analysisMessage 23 · Opaque
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

primitives: Remove todo

This commit only changes a code comment. It replaces a developer TODO note with a short explanation that the code is verbose because it implements a state machine. No code behavior, logic, or security properties changed.

e62e553dby Tobin C. Harding+1−11 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 candidatehashes: Interleave two independent hashes for 2-way SHA256dby jrakibi · ee04a988 · Apr 14, 2026 · 1 fileMessage 81 · StrongInformational 17Details
Commit message · jrakibi

hashes: Interleave two independent hashes for 2-way SHA256d

x86 SHA256RNDS2 has a latency of 4-6 cycles depending on
the architecture. the next SHA256RNDS2 needs the result
of the current one as input, so the CPU has to wait until
it is ready. (in Transform 2 for eg, 3 out of every 4 cycles
are wasted doing nothing)

we fill those wasted cycles by computing a second independent
hash alongside the first.

See https://uops.info/html-instr/SHA256RNDS2_XMM_XMM.html
for per-architecture instruction timings.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 17/100

This commit is a performance optimization for Bitcoin's double-SHA256 hashing on modern Intel/AMD processors. It rewrites a low-level routine to compute two independent hashes at once instead of one, filling idle CPU cycles. There is no security fix or vulnerability here; it is purely about making hashing faster.

Security candidatehashes: Add optimized x86 SHA256d for 64-byte inputby jrakibi · 301c3c16 · Apr 14, 2026 · 1 fileMessage 73 · AdequateInformational 16Details
Commit message · jrakibi

hashes: Add optimized x86 SHA256d for 64-byte input

Add the three transforms for sha256(sha256(64_bytes))

Transforms 1 & 2 compute the inner `sha256(64_bytes)`:

- Transform 1: 64 bytes already fill the first block (no
padding needed), so we apply 64 rounds of compression
normally.
After T1: state = state + initial_state

- Transform 2: the message schedule at this step is constant
and known in advance (64 bytes of padding), so
we precompute W[i]+K[i] into MIDS and apply 64 rounds (no
schedule expansion needed).
After T2: state = state + saved_T1_state
(state now contains sha256(64_bytes))

- Transform 3 computes sha256(output_of_T1_and_T2). The output
is 32 bytes, so the block contains 32 bytes and the rest is
known padding. we precompute the message
schedule for the known words (w8-w15) into FINS.
After T3: state = state + initial_state
(state now contains the sha256d result)

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 16/100

This commit adds a new, highly optimized x86 implementation for computing a double SHA-256 hash (SHA256d) on exactly 64 bytes of input. It uses Intel SHA-NI CPU instructions and precomputed constants to speed up Bitcoin-style hashing. There is no indication in the commit that this fixes a security bug; it appears to be a pure performance optimization.

Security candidatehashes: use consistent round numbering in sha256 commentsby jrakibi · d61ad42b · Apr 14, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · jrakibi

hashes: use consistent round numbering in sha256 comments

the 1-way ARM and x86 SHA-NI functions used Rounds 0-3 while
the 2-way ARM function used Rounds 1-4 in the comments.

use this consistently everywhere.

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 only changes comments in the SHA-256 code. It makes the round-number labels consistent between different versions of the optimized code (ARM and x86). No actual program logic, math, or behavior was changed, so it cannot affect security or correctness.

Security candidatehashes: split sha256 crypto int separate filesby jrakibi · a8e9c992 · Apr 13, 2026 · 4 filesMessage 68 · AdequateInformational 15Details
Commit message · jrakibi

hashes: split sha256 crypto int separate files

since we are planning to add other implementations for sha256: 2-way x86 shani,
4-way SSE4.1, and 8-way AVX2, we can split the file so each impl has
its own file without ending up with a single file that is hard to review.

this is just a code move, no logic change.

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 pure file reorganization: it splits the SHA-256 cryptographic implementation from one large file into several smaller files. The author explicitly states there is no logic change, and the diff shows the same code being moved into new modules with only minor module wiring adjustments. There is no security-relevant change visible.

Security candidateAdd psbt fuzz targetby Shing Him Ng · 390582f4 · Apr 11, 2026 · 5 filesMessage 38 · OpaqueInformational 12Details
Commit message · Shing Him Ng

Add psbt fuzz target

38/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Mentions testing or verification! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
signing boundaryfuzzing or regression evidencecryptography-sensitive pathsigning or wallet path
AI analysis · Informational 12/100

This commit adds a new automated fuzz-testing target for Partially Signed Bitcoin Transactions (PSBTs) in the rust-bitcoin project. It does not change production behavior, fix a bug, or alter any user-facing API. It only adds test infrastructure and small helper implementations needed to generate random PSBT-like objects for fuzzing. The fuzz target itself even documents a pre-existing known panic condition it works around, rather than fixing it.

Security candidatep2p: Implement ExactSizeEncoder for AddrV2Encoderby Mitchell Bagot · cbc14d2a · Apr 9, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Mitchell Bagot

p2p: Implement ExactSizeEncoder for AddrV2Encoder

For encoders, the use of the encoder_newtype_exact macro allows for
the implementation of the ExactSizeEncoder trait. This provides users
with the ability to determine the encoding length of types without
needing to perform the entire encoding process. Since the AddrV2Encoder
can do the necessary calculation in constant time, this trait should
be implemented for it too.

Implement ExactSizeEncoder for AddrV2Encoder.
Add test cases to confirm correct encoding + length calculation for
all types of AddrV2.

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

This commit adds a small performance and convenience feature to a Bitcoin peer-to-peer networking library written in Rust. It lets callers ask up front how many bytes an address encoding will produce, without actually doing the encoding. There is no security bug being fixed here; it is a routine enhancement with new tests.

Security candidatekey: Make as_inner pub(super) for secret key typesby Mitchell Bagot · cee439d8 · Apr 9, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

key: Make as_inner pub(super) for secret key types

As part of the long-term goal to remove the need to access the inner
secp types for all key types, the secret keys can now have their
inner accessor functions made pub(super). These functions are still
needed for functionality in the key module, but are no longer
necessary in the bitcoin crate or in the wider ecosystem.

Make as_inner pub(super) on PrivateKey and Keypair.

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

This commit narrows the visibility of two internal accessor methods from public to crate-internal. It is a routine API-cleanup change with no security relevance: it does not fix a bug, change behavior, or address any reported vulnerability.

Security candidatekey: Add From conversions for references for secret key typesby Mitchell Bagot · c55661dd · Apr 9, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

key: Add From conversions for references for secret key types

As with the changes to the from_* functions, there should exist From
impls that take references for all From impls that work on secret key
types. This further simplifies working with the non-Copy secret types.

Add From<&TweakedKeypair> for &Keypair, From<&PrivateKey> for Keypair
and From<&TweakedKeypair> for TweakedPublicKey.

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

This commit adds new Rust conversion helpers (From trait implementations) that let callers pass secret key types by reference instead of by value. It is a routine ergonomic/API improvement and does not change security behavior. The existing logic for deriving public keys from secret keys is unchanged; only the way callers provide the input is made more convenient.

Security candidatekey: Adjust all from_* functions to take refsby Mitchell Bagot · 0af1a681 · Apr 9, 2026 · 2 filesMessage 68 · AdequateInformational 19Details
Commit message · Mitchell Bagot

key: Adjust all from_* functions to take refs

The secret key types in bitcoin are no longer Copy. Since some
conversions to public key types take the key types by value, this makes
the use of private keys fairly unergonomic. Except where necessary,
conversion constructors for all key types (that is, from_* functions)
should always take references. This can help avoid costly copies.

Change from_keypair on TweakedPublicKey, from_private_key on
CompressedPublicKey and from_secret_bytes on PrivateKey to all take
references instead of values.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialcryptography-sensitive pathsigning or wallet path
AI analysis · Informational 19/100

This commit is a routine ergonomic/API change in the rust-bitcoin library. It changes several key-conversion functions so they accept references instead of taking ownership of private key and keypair values. There is no security bug being fixed and no new vulnerability being introduced; it simply makes the API easier to use after the underlying secret key types stopped being implicitly copyable.

Security candidateAdd panics section to docsby Jamil Lambert, PhD · 43dae788 · Apr 8, 2026 · 3 filesMessage 45 · ThinInformational 15Details
Commit message · Jamil Lambert, PhD

Add panics section to docs

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

This commit only adds documentation comments describing when three functions can panic. No code behavior was changed, so it cannot introduce or fix a security vulnerability on its own.

Security candidateDocs cleanupby Jamil Lambert, PhD · f68ae3cb · Apr 8, 2026 · 2 filesMessage 33 · OpaqueInformational 15Details
Commit message · Jamil Lambert, PhD

Docs cleanup

Add a couple of missing full stops and capital letters.

33/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Provides an explanatory body! Too few words to establish purpose! Opaque security-relevant change
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit only fixes punctuation and capitalization in code comments (documentation). No program logic, behavior, or security properties were changed.

Security candidatebitcoin: Move key module errors to error submoduleby Mitchell Bagot · bd8f15bc · Apr 8, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Mitchell Bagot

bitcoin: Move key module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from key module into error submodule and re-export.

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 commit is a code cleanup that moves error type definitions into a new 'error' submodule and re-exports them so existing code keeps working. It does not change how keys are parsed, validated, or used, and it does not fix or introduce any security vulnerability.

Security candidatebitcoin: Move ecdsa module errors to error submoduleby Mitchell Bagot · 630ca5ac · Apr 8, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

bitcoin: Move ecdsa module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from ecdsa module into error submodule and re-export.

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 simple internal code cleanup in the rust-bitcoin library. It moves two error types (DecodeError and ParseSignatureError) from the main ECDSA module into a new 'error' submodule and re-exports them so existing code keeps working. There is no change to behavior, no bug fix, and no security issue.

Security candidatebitcoin: Move sighash module errors to error submoduleby Mitchell Bagot · e2d65253 · Apr 8, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

bitcoin: Move sighash module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from sighash module into error submodule and re-export.

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 pure internal code reorganization: it moves error type definitions from one place in the file to a new `error` submodule and re-exports them. There is no change to how the library behaves, no bug fix, and no security-relevant change.

Security candidatebitcoin: Move bip32 module errors to error submoduleby Mitchell Bagot · 9d80f54b · Apr 8, 2026 · 1 fileMessage 73 · AdequateInformational 20Details
Commit message · Mitchell Bagot

bitcoin: Move bip32 module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from bip32 module into error submodule and re-export.

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

This commit is a pure code reorganization: it moves several BIP-32 error type definitions from the main bip32.rs file into a new error submodule and re-exports them so existing code keeps working. There are no functional changes to how keys are derived, parsed, or validated, and no security bug is fixed or introduced.

Security candidatefuzz: pin cargo-fuzz to 0.12.0by Ismail Daif · 40fa0cac · Apr 7, 2026 · 1 fileMessage 55 · ThinInformational 15Details
Commit message · Ismail Daif

fuzz: pin cargo-fuzz to 0.12.0

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
access controlfuzzing or regression evidence
AI analysis · Informational 15/100

This change pins the version of a fuzzing tool used only in internal testing. It does not alter any code that end users run, and there is no indication it fixes a security vulnerability.

Security candidatebitcoin: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 1f112e54 · Apr 7, 2026 · 7 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

bitcoin: Add explicit None return impl for std::error::Error

The std::error::Error impls on many error types rely on the default
implementation for the trait, which returns None. While these are
correct, explicit return values make the functionality more obvious to
later developers without requiring pre-existing knowledge of the trait
or needing to search documentation.

Replace all default impls of std::error::Error with explicit impls
returning None. For enum errors, also return None for each match arm.

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 code clarity improvement only. It replaces empty default implementations of Rust's standard error trait with explicit implementations that return 'None' for the underlying cause. The behavior is identical before and after the change; it just makes the code easier to read for future maintainers.

Security candidatehashes: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 417da1a3 · Apr 7, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

hashes: Add explicit None return impl for std::error::Error

The std::error::Error impls on many error types rely on the default
implementation for the trait, which returns None. While these are
correct, explicit return values make the functionality more obvious to
later developers without requiring pre-existing knowledge of the trait
or needing to search documentation.

Replace all default impls of std::error::Error with explicit impls
returning None.

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 minor code cleanup with no security impact. It changes two Rust error types to explicitly state that they do not wrap another underlying error, instead of relying on the programming language's default behavior. The actual program behavior is unchanged.

Security candidatehashes: Add a full stop to the sha256 error module commentby Mitchell Bagot · feaa7506 · Apr 7, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Mitchell Bagot

hashes: Add a full stop to the sha256 error module comment

This was missing from the the original PR, but should be included
because publicly visible doc comments should always be well-formed
English.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a trivial documentation fix: it adds a single missing period to a public comment in the SHA256 error module. There is no code change and no security relevance.

Security candidateRename PublicKey to LegacyPublicKeyby Mitchell Bagot · a3ac05b6 · Apr 4, 2026 · 13 filesMessage 58 · ThinInformational 19Details
Commit message · Mitchell Bagot

Rename PublicKey to LegacyPublicKey

The optionally-compressed PublicKey type is no longer used in Bitcoin
outside of legacy transaction handling. Since the name PublicKey
implies a general purpose public key type, it should be renamed to
clarify the niche use compared to the typical compressed public key
type, FullPublicKey.

Rename PublicKey to LegacyPublicKey.
Deprecate PublicKey.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 19/100

This commit is a routine API cleanup: it renames the `PublicKey` type to `LegacyPublicKey` in the rust-bitcoin library and keeps `PublicKey` as a deprecated alias so existing code continues to compile. There is no bug fix, behavior change, or security patch in the diff.

Security candidateRename CompressedPublicKey to FullPublicKeyby Mitchell Bagot · 1c153870 · Apr 4, 2026 · 11 filesMessage 58 · ThinInformational 20Details
Commit message · Mitchell Bagot

Rename CompressedPublicKey to FullPublicKey

The CompressedPublicKey represents an always compressed ECDSA public
key. This key type is the standard for almost all transactions in
modern Bitcoin. As such, it should be renamed to better clarify
its purpose.

Rename CompressedPublicKey to FullPublicKey.
Deprecate CompressedPublicKey.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 20/100

This commit is a simple rename of a Rust type from CompressedPublicKey to FullPublicKey, with the old name kept as a deprecated alias. It does not change any behavior, cryptographic logic, or security properties. It is an API cleanup, not a security fix or vulnerability.

Security candidatefuzz: Replace Unstructured with auto Arbitrary arg for do_testby Mitchell Bagot · 3c9e3374 · Apr 3, 2026 · 5 filesMessage 91 · StrongInformational 15Details
Commit message · Mitchell Bagot

fuzz: Replace Unstructured with auto Arbitrary arg for do_test

With the new libfuzzer backend for the fuzz targets, types that
implement Arbitrary can be directly constructed as arguments to the
fuzz_target! callback, rather than taking a byte slice, running it
through Unstructured and then calling Arbitrary impls manually.

ref:
https://rust-fuzz.github.io/book/cargo-fuzz/structure-aware-fuzzing.html

Replace manual arbitrary use with an automatic Arbitrary argument in
arbitrary_block, arbitrary_transaction, arbitrary_witness,
deserialize_psbt and arbitrary_addrv2 fuzz targets.

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundaryfuzzing or regression evidencesigning or wallet path
AI analysis · Informational 15/100

This commit is a refactoring of internal fuzz-testing code only. It changes how test inputs are generated for automated fuzzing targets, switching from a manual byte-slice approach to a newer automatic approach supported by the fuzzing library. It does not change any production Bitcoin parsing, validation, or networking code, and it does not fix or introduce any security vulnerability.

Security candidatehashes: Move errors in sha256 to error submoduleby Mitchell Bagot · f2f6ac12 · Apr 3, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

hashes: Move errors in sha256 to error submodule

As with the other crates, errors in hashes should be moved to
submodules for each of the top-level modules. Any errors should then
be no_inline re-exported in the top-level module.

Move MidstateError to new error submodule and re-export in sha256.

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 definition of an error type called MidstateError into a new 'error' submodule within the SHA256 code, then re-exports it at the original location so existing users are unaffected. There is no functional change to how the code behaves.

Security candidateAdd homepage metadata for all cratesby Mitchell Bagot · 4c9fa4a1 · Apr 3, 2026 · 14 filesMessage 76 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Add homepage metadata for all crates

Per the Rust API guidelines:
The homepage metadata should only be set if there is a unique website
for the crate other than the source repository or API documentation.

Add "https://rust-bitcoin.org" homepage to all crate manifests.

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit only adds a website link (homepage metadata) to the package description files for all crates in the rust-bitcoin project. It does not change any code, logic, or security behavior. There is no security issue here.

Security candidateMove From<Infallible> impls below typeby Tobin C. Harding · 06c845cd · Apr 2, 2026 · 7 filesMessage 68 · AdequateInformational 15Details
Commit message · Tobin C. Harding

Move From<Infallible> impls below type

As is customary put the impl below its type. However when there is an
impl block for the error type put the `From` below that. Note the
layout is then

1. Type definition
2. [Type impl block]
3. `From<Infallible>` for type
4. `Display`
5. `std::error::Error`
6. [other `From` impls]

Anal I know. Code move only.

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 only moves existing code around. It reorders where certain `From<Infallible>` implementations and error trait implementations appear in the source files so they follow a consistent layout convention. No behavior, logic, or security properties of the code are changed.