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 queue1955AI analyses
183commits · 30 days
400commits · 60 days
1283commits · 180 days
2057commits · 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 Bagot640192640068
Tobin C. Harding40965361063
jrakibi944993068
Nick Johnson18920186059
Andrew Poelstra512039075
Jamil Lambert, PhD11418109061
Fmt Bot311431045
Trevor Arjeski111111069
Shing Him Ng31727056
Ismail Daif22622050
satsfy (Renato Britto)17617066
Martin Habovstiak27527069
Analysis record

Published AI watches

Last scanned 0 minutes ago

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

Merge rust-bitcoin/rust-bitcoin#6671: units: reword docs from height to count in relative locktime

This commit only changes documentation comments and variable names in the rust-bitcoin library. It rewords references to 'block height' as 'block count' for relative locktime, because a relative locktime measures elapsed blocks since a coi…

6ea4ff92by Andrew Poelstra+20−172 files
No security note in commit
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 15 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

units: reword docs to block count in relative locktime

This commit only rewords documentation comments and variable names in the codebase. It changes references from 'block height' to 'block count' for relative lock times, which is a terminology correction with no functional code changes. Ther…

8867fe2eby satsfy (Renato Britto)+20−172 files
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6667: Make the `WitnessesEncoder` private

This commit makes a small internal helper type called WitnessesEncoder private. It was previously exported as public API but is only used inside the transaction encoder. The change removes it from the public API surface and moves the code …

07d91f7fby Andrew Poelstra+54−1324 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 19 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6661: units: Remove `From<u16>` from `NumberOfBlocks`

This is a routine API cleanup, not a security fix. The developers removed a shortcut that let programmers create a 'number of blocks' value directly from any u16 number, replacing it with an existing named constructor called from_height. T…

ed5f1b68by Andrew Poelstra+18−358 files
No security note in commit
Informational 15 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6668: Scrub the transaction encoding logic

This commit is a pure code reorganization (refactor) in the rust-bitcoin library. It moves transaction encoding and decoding definitions around within a single file so the code follows the project's preferred layout. No logic, behavior, or…

c5588ba5by Andrew Poelstra+57−571 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 96 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6663: build(deps): bump taiki-e/install-action from 2.79.12 to 2.81.4

This is a routine Dependabot update that bumps the version of a third-party GitHub Action used only in automated testing workflows. The change does not touch the project's actual Bitcoin library code, and there is no indication it fixes or…

5c92c0b0by Andrew Poelstra+2−22 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Update the API text files

This commit only updates two generated API text files that list the public surface of the Rust crate. It removes entries for a `WitnessesEncoder` type, reflecting that the type is no longer part of the public API. There is no source code c…

9c391145by Tobin C. Harding+0−782 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 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

release bitcoin_hashes 1.2.0

This commit is a routine version bump for the bitcoin_hashes library from version 1.1.0 to 1.2.0. It only updates lock files, the package version number, and the changelog. There is no code change and no security relevance visible in the c…

8899dfd2by Andrew Poelstra+27−224 files
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.1.0 to 8.2.0

This is a routine automated update by Dependabot that changes the pinned version of a GitHub Action used to install the 'uv' Python tool in two workflow files. The new commit hash corresponds to the legitimate 8.2.0 release of astral-sh/se…

1c438632by dependabot[bot]+2−22 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 automated update by Dependabot that changes the pinned version of a GitHub-provided security scanning helper used in a workflow. It does not modify the project's actual Bitcoin library code, its cryptographic logic, or an…

5293bee4by 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 taiki-e/install-action from 2.79.12 to 2.81.4

This is a routine Dependabot update that bumps a GitHub Actions helper used in automated testing workflows from version 2.79.12 to 2.81.4. It only changes which version of the action is invoked during CI runs; it does not modify the Rust B…

eb9544f9by dependabot[bot]+2−22 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
Repository ledger

Explore captured commits

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

Lower-prioritybase58: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 207737bb · Apr 7, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

base58: 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
AI analysis · Informational 15/100

This commit is a minor code-clarity change. It rewrites three standard Rust error trait implementations to explicitly state that these errors have no underlying cause, instead of relying on the trait's automatic default. The behavior is identical before and after; no security issue is introduced or fixed.

Lower-priorityp2p: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 04ae6a3f · Apr 7, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

p2p: 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
AI analysis · Informational 15/100

This commit is a straightforward code cleanup. It rewrites several Rust error-type definitions so they explicitly state that they have no underlying 'cause' error, instead of relying on the programming language's automatic default. The behavior of the program is unchanged, and there is no security issue.

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.

Lower-priorityconsensus_encoding: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 1fe11a54 · Apr 7, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

consensus_encoding: 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
AI analysis · Informational 15/100

This commit is a minor code-clarity change. It rewrites two standard Rust error trait implementations to explicitly state that these errors have no underlying cause, instead of relying on Rust's automatic default. There is no functional change and no security relevance.

Lower-priorityprimitives: Add explicit None return impl for std::error::Errorby Mitchell Bagot · 8c9a4858 · Apr 7, 2026 · 4 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

primitives: 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
AI analysis · Informational 15/100

This commit is a straightforward code clarity improvement. It rewrites several Rust error-type definitions so that they explicitly state they have no underlying cause, instead of silently relying on a default behavior. There is no functional change and no security impact.

Lower-priorityunits: Add explicit None return impl for std::error::Errorby Mitchell Bagot · ce87bb11 · Apr 7, 2026 · 7 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

units: 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
AI analysis · Informational 15/100

This commit is a pure code-style/documentation change. It replaces empty default implementations of Rust's standard error trait with explicit implementations that return 'no underlying cause' (None). The behavior is identical before and after; nothing about security or program logic changes.

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.

Lower-priorityCI: Update to latest cargo-rbmtby Tobin C. Harding · df5c1605 · Apr 6, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Tobin C. Harding

CI: Update to latest cargo-rbmt

We are a few commits back; use the commit hash of current tip of
master.

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit simply updates the version (commit hash) of an internal GitHub Actions helper tool used in the project's continuous integration (CI) pipelines. There is no change to the actual Rust Bitcoin library code, no user-facing behavior change, and no security fix or vulnerability patch visible in the diff.

Lower-priority2026-04-05 automated rustfmt nightlyby Fmt Bot · 3582e51b · Apr 5, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Fmt Bot

2026-04-05 automated rustfmt nightly

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This is a purely cosmetic code-formatting change made by an automated rustfmt tool. It rewrites one type alias definition in a single file to fit on fewer lines. There is no functional change, no bug fix, and no security relevance.

Lower-prioritybitcoin: update CompactSize Kani proofsby Ismail Daif · 11bb6a8a · Apr 4, 2026 · 1 fileMessage 45 · ThinInformational 12Details
Commit message · Ismail Daif

bitcoin: update CompactSize Kani proofs

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 12/100

This commit updates formal verification tests (Kani proofs) for CompactSize encoding. It does not change any production code. The change makes the proofs check that oversized values are correctly rejected, rather than checking round-trips for very large values. There is no indication this fixes a security bug in the actual library.

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.

AI review queuedprimitives: Update API filesby Mitchell Bagot · d723402f · Apr 4, 2026 · 3 filesMessage 35 · OpaqueInformational 15Details
Commit message · Mitchell Bagot

primitives: Update API files

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
documentation-only discountsecond-pass: opaque commit message
AI analysis · Informational 15/100

This commit only updates generated API snapshot text files for the rust-bitcoin primitives crate. It reflects a code reorganization where error types were moved into a new `error` submodule (for example, `bitcoin_primitives::block::ParseBlockError` became `bitcoin_primitives::block::error::ParseBlockError`). No actual source code, logic, or behavior changed, so there is no security impact.

Lower-priorityprimitives: Move block module errors to error submoduleby Mitchell Bagot · a21562b9 · Apr 4, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

primitives: Move block module errors to error submodule

At present, some modules in primitives 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 block module into error submodule and re-export.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a routine code cleanup. It moves several error type definitions from the main block module into a new `error` submodule and adjusts how those error types are publicly re-exported. There is no change to how blocks are validated, parsed, or encoded, and no security bug is fixed.

Lower-priorityprimitives: Move witness module errors to error submoduleby Mitchell Bagot · ad3685dc · Apr 4, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

primitives: Move witness module errors to error submodule

At present, some modules in primitives 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 witness module into error submodule and
re-export.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a simple internal code reorganization. It moves two error types (WitnessDecoderError and UnexpectedEofError) from the main witness module into a new error submodule and re-exports them so existing code keeps working. There is no functional change to how witness data is decoded or validated.

AI review queuedprimitives: Move transaction module errors to error submoduleby Mitchell Bagot · 2d97f3e4 · Apr 4, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

primitives: Move transaction module errors to error submodule

At present, some modules in primitives 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 transaction 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
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a routine code cleanup in the rust-bitcoin library. It moves error type definitions for Bitcoin transactions into a new 'error' submodule and re-exports them, without changing what the errors mean or how transactions are validated. There is no security fix or behavior change.

Lower-priorityprimitives: Move script module errors to error submoduleby Mitchell Bagot · 1c39cc5f · Apr 4, 2026 · 4 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

primitives: Move script module errors to error submodule

At present, some modules in primitives 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 script module into error submodule and re-export.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a routine code cleanup with no security relevance. It moves Bitcoin script error types into a dedicated 'error' submodule and re-exports them so the public API stays the same. There are no functional changes to how scripts are parsed, validated, or executed.

AI review queuedFix cargo-rmbt typoby Ismail Daif · 65501616 · Apr 3, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Ismail Daif

Fix cargo-rmbt typo

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit fixes a spelling mistake in an error message inside a maintainer helper script. The message previously said 'cargo-rmbt' when it should have said 'cargo-rbmt'. There is no change to program behavior, no security fix, and no risk to users of the library.

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.

Lower-priorityp2p: Add derives to encoders and decodersby Mitchell Bagot · 66d2e868 · Apr 3, 2026 · 10 filesMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

p2p: Add derives to encoders and decoders

The encoder and decoder types should all have the Debug and Clone
traits implemented. Since the underlying encoders and decoders all have
Clone and Debug, we can use #[derive] to implement them for all
encoders and decoders in p2p.

Add #[derive(Debug, Clone)] to all encoders and decoders in p2p.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit simply adds standard Rust helper traits (Debug for printing and Clone for copying) to a large set of P2P message encoder and decoder types. It does not change any behavior, parsing logic, or security checks. There is no security issue here.

Lower-prioritybase58: Make error re-exports #[doc(no_inline)]by Mitchell Bagot · 5ab2df5a · Apr 3, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

base58: Make error re-exports #[doc(no_inline)]

To match the standard set elsewhere, re-exports of errors in top-level
modules of each crate should be #[doc(no_inline)].

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit changes a documentation-only Rust attribute on public error re-exports. It tells the documentation generator not to inline the details of these error types on the crate's main page. There is no change to executable code, behavior, or security.

Lower-prioritychacha20_poly1305: Move errors to error submoduleby Mitchell Bagot · 44b61406 · Apr 3, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

chacha20_poly1305: Move errors to error submodule

As part of the process of moving errors to dedicated error submodules,
the main error type in the chacha20 crate should also be moved to a
submodule. While this error type is currently in the root and not a
top-level module, the same pattern should still apply.

Move Error type to error submodule and re-export error type as
no_inline.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a simple internal code reorganization. It moves the existing 'Error' type into a new 'error' submodule and re-exports it so users can still access it the same way. There is no change to how encryption, decryption, or authentication works, and no security bug is fixed or introduced.

Lower-priorityhashes: Move errors in hkdf to error submoduleby Mitchell Bagot · edeb4ee3 · Apr 3, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

hashes: Move errors in hkdf 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 MaxLengthError to new error submodule and re-export in hkdf.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a routine code reorganization. It moves an existing error type (MaxLengthError) from the main HKDF module into a new 'error' submodule and re-exports it publicly. There is no functional change to how the code behaves, no bug fix, and no security improvement or regression.

AI review queuedhashes: Update API filesby Mitchell Bagot · 58c698f1 · Apr 3, 2026 · 3 filesMessage 28 · OpaqueInformational 15Details
Commit message · Mitchell Bagot

hashes: Update API files

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
documentation-only discountsecond-pass: opaque commit message
AI analysis · Informational 15/100

This commit only updates generated API snapshot files (text files listing public types and functions) to reflect that two error types were moved into new `error` submodules. No actual source code, logic, or behavior changed. It is a documentation/tracking update for the crate's public API surface and has no security relevance on its own.