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 48 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 candidatecrypto: Bump version to 0.2.0by Tobin C. Harding · 3e739986 · Apr 27, 2026 · 6 filesMessage 68 · AdequateInformational 15Details
Commit message · Tobin C. Harding

crypto: Bump version to 0.2.0

Bump the `crypto` version. Update the dep in `bitcoin` and add an
explicit version number in `taproot-primitives`.

In preparation add a changelog entry, bump the version number, and
update the lock files.

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 version bump for an internal Rust library called `bitcoin-crypto` from version 0.1.0 to 0.2.0. It updates version numbers in package files, lock files, and a changelog. There are no code changes that fix or introduce security behavior.

Security candidateDelete psbt moduleby Tobin C. Harding · bdc61c46 · Apr 27, 2026 · 21 filesMessage 81 · StrongInformational 18Details
Commit message · Tobin C. Harding

Delete psbt module

In #6055 we deprecated the `psbt` module on the `0.32.x` branch. Now
we can delete it from master.

### Context

Development of the PSBT has moved to a separate crate. Hosted on the
new Forgejo instance at:

https://git.rust-bitcoin.org/rust-bitcoin/rust-psbt

Crate name is `psbt-v2` because it has initial support for PSBTv2. The
crate also includes all code from the `0.32.x` branch (as well as
miniscript code). In other words the crate is a drop in replacement
for the `Psbt` type and its functionality.

During release of `psbt-v2 v0.3.0` we attempted to ensure feature
parity with `0.32.x` since the actual migration was done a while back.

The road map for dev of `psbt-v2` is loosely:

- Improve PSBTv2 stuff
- Continue work on supporting Silent Payments
- Use crate as a test bed for the process of upgrade of `bitcoin 0.32.x`


Exact strategy of the last point is being worked on. We are
investigating creating a bunch of step-by-step releases to help the
process. To prove (and develop) the process we plan on using:

- miniscript
- psbt-v2
- corepc

81/100 · StrongMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarycryptography-sensitive pathsigning or wallet path
AI analysis · Informational 18/100

This commit removes the entire PSBT (Partially Signed Bitcoin Transaction) module from the rust-bitcoin library on the master branch. It is a planned code cleanup, not a security fix. The PSBT functionality has been moved to a separate crate called psbt-v2, and the old module was already deprecated in a previous release. Users who relied on the built-in PSBT support will need to migrate to the new crate when upgrading.

AI review queuedfuzz: Migrate p2p fuzz targets to new encodingby rustaceanrob · 012ea1e6 · Apr 26, 2026 · 3 filesMessage 55 · ThinInformational 15Details
Commit message · rustaceanrob

fuzz: Migrate p2p fuzz targets to new encoding

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
fuzzing or regression evidencesigning or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only updates internal fuzz testing code to use a newer encoding/decoding helper crate. It does not change any production code that real users or network peers would run, and it does not fix or introduce any security vulnerability.

Security candidatehashes: Add x86 AVX2 8-way dispatchby jrakibi · 9cc9b338 · Apr 25, 2026 · 1 fileMessage 45 · ThinInformational 17Details
Commit message · jrakibi

hashes: Add x86 AVX2 8-way dispatch

add dispatcher that handles 8-way

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

This commit adds a new performance optimization for SHA-256 hashing on modern x86 processors that support AVX2 instructions. It enables the library to process up to 8 hash calculations at once when the CPU supports it. There is no indication in the commit that this fixes a security bug; it appears to be a routine performance improvement.

Security candidatehashes: fold 8-way AVX2 SHA256d into round! macroby jrakibi · 41cc7afd · Apr 25, 2026 · 1 fileMessage 68 · AdequateInformational 18Details
Commit message · jrakibi

hashes: fold 8-way AVX2 SHA256d into round! macro

use a round! macro to cut ~1060 lines from the unrolled version.
each round becomes a single round!(...) call that almost matches
Core's Transform_8way line-by-line, so it's easy to compare and
review against sha256_avx2.cpp.

refactor, no behavior 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 18/100

This commit is a code cleanup in the SHA-256 hashing implementation. It replaces roughly 1,000 lines of manually repeated hashing steps with a few short macros that generate the same instructions. The author explicitly states there is no behavior change, and the diff only restructures existing operations without altering constants, math, or control flow.

Security candidatehashes: Add 8-way AVX2 SHA256d for 64-byte inputby jrakibi · d299082d · Apr 25, 2026 · 2 filesMessage 68 · AdequateInformational 16Details
Commit message · jrakibi

hashes: Add 8-way AVX2 SHA256d for 64-byte input

add the three transforms for sha256(sha256(64_bytes)) using AVX2
SIMD.

AVX2 uses 256-bit registers, so we can pack eight 32-bit words into
each register and compute 8 independent hashes in parallel with a
single SIMD op.

- Transforms 1 & 2 compute the inner `sha256(64_bytes)`.
- Transform 3 computes sha256(output_of_T1_and_T2).

rounds are fully unrolled (we will use a round! macro to fold them
in the next patch).

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

This commit adds a new, highly optimized implementation of the SHA256d hashing algorithm for 64-byte inputs, using Intel AVX2 processor instructions. It is a pure performance optimization that computes eight hashes at once. There is no indication in the commit that it fixes a security bug; it simply adds a faster code path.

Security candidateRun the formatterby Mitchell Bagot · ad434204 · Apr 24, 2026 · 4 filesMessage 28 · OpaqueInformational 15Details
Commit message · Mitchell Bagot

Run the formatter

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is purely a code-formatting cleanup. It only changes whitespace, line breaks, and import order to match the project's style rules. No program logic, behavior, or security properties were changed.

Security candidateUse drain instead of flushby Tobin C. Harding · 6581b954 · Apr 23, 2026 · 6 filesMessage 68 · AdequateInformational 15Details
Commit message · Tobin C. Harding

Use drain instead of flush

The term 'flush' has meaning already in respect to a std writer thus
impiles that a function with 'flush' in the name would call
`writer.flush()` but we do not.

After debate we reached consensus on the verb 'drain' to replace
'flush'.

Rename all 'flush_to_writer' functions to be `drain_to_writer`
repository wide. To keep our API uniform also re-name `flush_to_vec`
to be `drain_to_vec`.

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 simple rename of internal functions from 'flush_to_writer' and 'flush_to_vec' to 'drain_to_writer' and 'drain_to_vec'. The word 'flush' was confusing because it normally means something specific in I/O code, so the team chose 'drain' instead. No behavior changed, and there is no security issue.

AI review queuedMove importby Tobin C. Harding · a9cf222d · Apr 23, 2026 · 1 fileMessage 13 · OpaqueInformational 15Details
Commit message · Tobin C. Harding

Move import

There is an unrelated lint warning, no clue how it started showing up
but its a trivial fix. Move import from one feature gated scope to
another.

13/100 · OpaqueMessage clarity
✓ Provides detailed explanatory context! Very short subject! Too few words to establish purpose
Why it was queued
signing or wallet pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a minor code cleanup: it moves a Rust import statement (`use core::fmt;`) from one feature-gated code block to another. The change fixes a compiler lint warning and does not alter any program behavior or security logic.

Security candidatecrypto: Remove bitcoin-io dependencyby Mitchell Bagot · 9f5ece75 · Apr 23, 2026 · 4 filesMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

crypto: Remove bitcoin-io dependency

With the removal of the io-dependent functions from the key and
signature types, the bitcoin-io dependency can be entirely dropped from
the crypto crate.

Remove bitcoin-io dependency from manifest and update lock files.
Remove io re-export from crate root.

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

This commit is a routine cleanup that removes an unused dependency called bitcoin-io from the crypto crate. It only touches package metadata and lock files, not any code that handles keys, signatures, or user data. There is no security issue visible in this change.

Security candidateRemove io methods on public key typesby Mitchell Bagot · dc6c4888 · Apr 23, 2026 · 2 filesMessage 78 · AdequateInformational 17Details
Commit message · Mitchell Bagot

Remove io methods on public key types

The read_from and write_into functions on the public key types rely on
the bitcoin-io Read and Write traits. Since we want to remove the
dependence on io for the crypto crate, these methods must also be
removed. With the Serialized* types, the write_into methods are trivial
to replace inline.

Remove read_from and write_into methods from public key types and test
case for them.

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

This commit removes convenience methods for reading and writing public keys from/to byte streams in the rust-bitcoin crypto crate. It is a routine API cleanup to reduce dependency on the bitcoin-io crate, not a security fix. There is no evidence in the commit or supplied references that this change addresses a vulnerability.

Security candidatehashes: change engine parameter to be mutable referenceby yancy · 688cf1e7 · Apr 22, 2026 · 3 filesMessage 73 · AdequateInformational 18Details
Commit message · yancy

hashes: change engine parameter to be mutable reference

Allow engine parameter to be less restrictive in use. By changing the
parameter to `&mut`, the calling function no longer needs give up
ownership of engine.

The return value is removed since the caller can simply use existing
ownership of variable instead of the return value.

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

This is a routine internal API cleanup in the rust-bitcoin hashing library. A helper function that feeds data into a hash calculator is changed so callers pass in the calculator by mutable reference instead of handing it over and getting it back. No security vulnerability is present in the diff; it is a usability and ownership-style refactor.

Security candidatehashes: Add 4-way dispatcherby jrakibi · e26ee477 · Apr 22, 2026 · 1 fileMessage 60 · AdequateInformational 17Details
Commit message · jrakibi

hashes: Add 4-way dispatcher

add x86 sha256d dispatcher that handles 4-way SSE4.1

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 17/100

This commit adds a new performance optimization for SHA-256 hashing on modern x86 processors. It introduces a code path that processes four blocks at once using SSE4.1 instructions when available. There is no indication in the commit that this fixes a security vulnerability; it appears to be a routine performance improvement.

Security candidatehashes: fold 4-way SSE4.1 SHA256d into round! macroby jrakibi · d2f8f6f5 · Apr 22, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · jrakibi

hashes: fold 4-way SSE4.1 SHA256d into round! macro

use a round! macro to cut ~1000 lines from the unrolled version.
each round becomes a single round!(...) call. it almost matches Core
line-by-line, so it's easy to compare and review against sha256_sse41.cpp.

refactor, no behavior change.

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 in the Bitcoin library's SHA-256 hashing code. It replaces roughly 1,000 lines of manually repeated calculation steps with a few short macros that generate the same steps automatically. The author explicitly calls it a refactor with no behavior change, and the constants and arithmetic operations appear unchanged.

Security candidatehashes: Add 4-way SSE4.1 SHA256d for 64-byte inputby jrakibi · ea0f3035 · Apr 22, 2026 · 2 filesMessage 73 · AdequateInformational 16Details
Commit message · jrakibi

hashes: Add 4-way SSE4.1 SHA256d for 64-byte input

add the three transforms for sha256(sha256(64_bytes)) using SSE4.1 SIMD.

SSE4.1 uses 128-bit registers, so we can pack four 32-bit words into
each register and compute 4 independent hashes in parallel with a
single SIMD op.

- Transforms 1 & 2 compute the inner `sha256(64_bytes)`.
- Transform 3 computes sha256(output_of_T1_and_T2).

rounds are fully unrolled (we will use a round! macro to fold them
in the next patch).

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, faster way to calculate SHA256d hashes for 64-byte inputs on modern Intel/AMD processors using SSE4.1 CPU instructions. It is a pure performance optimization and does not appear to fix or introduce a security vulnerability based on the code shown. However, because it is new cryptographic code, any bug in it could in principle produce wrong hash results, which would be a correctness issue rather than a direct security flaw.

Security candidatecrypto: Adjust SerializedLegacyPublicKey docsby Mitchell Bagot · 16324919 · Apr 22, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Mitchell Bagot

crypto: Adjust SerializedLegacyPublicKey docs

The SerializedLegacyPublicKey docs don't mention the maximum size or
the lack of allocations like the ecdsa::SerializedSignature docs do.

Adjust wording of docs to mention lack of allocation and max size of
65 bytes.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 15/100

This commit only changes documentation wording for a Rust Bitcoin data type. It adds a note that the serialized legacy public key type avoids heap allocation and has a maximum size of 65 bytes. No code behavior was altered.

Security candidateRemove io write helpers from ecdsa signaturesby Mitchell Bagot · bffd1b0f · Apr 22, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Mitchell Bagot

Remove io write helpers from ecdsa signatures

In the ecdsa module, the SerializedSignature and Signature types have
helper methods for writing to bitcoin-io Write objects. Since we want
to remove the io dependency entirely, and the SerializedSignature can
already be used in a similar way to a slice, there's no point to
retaining them.

Remove Signature::serialize_to_writer and SerializedSignature::write_to.
Adjust existing io test case to use std traits.

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

This commit removes two helper methods that wrote ECDSA signatures to a custom I/O writer. It is a straightforward API cleanup to drop a dependency, not a security fix. There is no evidence of a vulnerability being patched.

Security candidateDon't abuse psbt Deserializeby Tobin C. Harding · cc1d5919 · Apr 22, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Tobin C. Harding

Don't abuse psbt Deserialize

I'm not sure what is the intention of this code or exactly how the
derives are working in the `taproot` module because we are importing
`psbt::serialize::Deserialize` and then using it in `serde` derives?

Also the `TapTree` arbitrary stuff is a bit odd, that is what led me
here while I was attempting to delete the `psbt` module.

So, I don't know if this is a bug or an internal change? Introduced in
commit: `37c9fce2a684 Implement `Arbitrary` for psbt types`.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit is a small internal cleanup in the rust-bitcoin library. It stops using a PSBT-specific deserialization helper to build test-only 'Arbitrary' instances of TapTree, and instead builds the tree directly from its internal NodeInfo. It also switches serde derives to use the proper serde::Deserialize trait. There is no direct evidence this fixes an exploitable security bug, but it removes a confusing and potentially incorrect reuse of PSBT serialization logic outside the PSBT module.

AI review queuedunits: scrub encoder/decoder layoutby Renato Britto · d06af66f · Apr 21, 2026 · 6 filesMessage 45 · ThinInformational 15Details
Commit message · Renato Britto

units: scrub encoder/decoder layout

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

This commit is a pure code cleanup in the rust-bitcoin library's 'units' module. It reorders where encoder and decoder definitions appear in six source files so that the Encodable and Decodable trait implementations come before the macro-generated encoder/decoder structs. No behavior, logic, or security properties change; it only makes the layout consistent.

AI review queuedImprove hex codec test coverageby Jamil Lambert, PhD · c51ee8db · Apr 21, 2026 · 3 filesMessage 55 · ThinInformational 15Details
Commit message · Jamil Lambert, PhD

Improve hex codec test coverage

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds new unit tests for the existing hexadecimal encoding/decoding code. It does not change any production logic, so it cannot introduce or fix a security vulnerability on its own.

Security candidatecrypto: Move SerializedLegacyPublicKey to cryptoby Mitchell Bagot · 8f809ccd · Apr 21, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Mitchell Bagot

crypto: Move SerializedLegacyPublicKey to crypto

Now that the SerializedLegacyPublicKey has been re-arranged to remove
the strict dependence on PushBytes, it can be trivially moved to the
crypto crate.

Move SerializedLegacyPublicKey to crypto crate and re-export from
bitcoin.
Move associated test to crypto key module.

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

This commit is a simple internal code reorganization. It moves the SerializedLegacyPublicKey type from the main bitcoin crate into the lower-level crypto crate and re-exports it so existing code keeps working. No behavior changes, no bug fixes, and no security implications are visible in the diff.

Security candidateRemove dependence on PushBytes for SerializedLegacyPublicKeyby Mitchell Bagot · 1f3051c9 · Apr 21, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Remove dependence on PushBytes for SerializedLegacyPublicKey

The SerializedLegacyPublicKey type currently relies on
Borrow<PushBytes> to implement the Borrow and AsRef for [u8]. Since
PushBytes is only in bitcoin, this prevents the simple move. Instead,
the main reference conversion should be Deref for [u8].

Move Deref impl into encapsulating module and redefine
Borrow<PushBytes> in terms of it. Adjust order of Borrow and AsRef
impls.

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 is a small internal code cleanup in the rust-bitcoin library. It changes how one public-key wrapper type exposes its underlying byte slice, removing a dependency on another type (PushBytes) so the code can be moved between crates more easily. There is no user-visible behavior change and no security fix.

Security candidatecrypto: Remove error conversion From implsby Mitchell Bagot · e986053a · Apr 20, 2026 · 2 filesMessage 68 · AdequateInformational 19Details
Commit message · Mitchell Bagot

crypto: Remove error conversion From impls

From impls for conversions between error types represent a public api
commitment. Since we can't know how the error types may need to change
as the crate progresses, it's best to remove these now and reintroduce
them later if we find them necessary and/or useful for users.

Remove all From<BarError> for FooError in crypto, replacing uses with
map_err where appropriate.

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

This commit removes automatic error-conversion shortcuts in the crypto module of the rust-bitcoin library. It does not fix a bug or vulnerability; it is a deliberate API cleanup to avoid promising too much to future users. Existing code that relied on the removed conversions will need minor updates, but runtime behavior is unchanged.

Security candidatecrypto: Re-export key types at crate rootby Mitchell Bagot · adf52bbc · Apr 20, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Mitchell Bagot

crypto: Re-export key types at crate root

Re-export the key types at the crate root, similar to the re-exports in
bitcoin.

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

This commit simply makes several existing key types easier to import by re-exporting them at the top level of the crypto crate. It does not change any behavior, logic, or security properties of the code.

Security candidatecrypto: Add pub extern crate for crates with public api typesby Mitchell Bagot · fd25de60 · Apr 20, 2026 · 1 fileMessage 85 · StrongInformational 16Details
Commit message · Mitchell Bagot

crypto: Add pub extern crate for crates with public api types

In crypto, various types from child crates are present in the public
api, including base58::Error, network::NetworkKind, secp256k1 keys and
io traits. In order to simplify dependency handling, these crates
should be exposed through pub extern crate exports in the root of the
crypto crate.

Add pub extern crate statements for base58, network, io and secp256k1.
Remove comment on hex_stable re-export to match new policy.

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

This change simply re-exports a few internal Rust crates through the public API of the `crypto` sub-crate so users don't have to add those dependencies manually. It is a routine dependency-management and API-ergonomics patch with no apparent security relevance.