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 queue248AI analyses
194commits · 30 days
405commits · 60 days
1283commits · 180 days
2070commits · 365 days
Backfill bands
Aug 5 → Feb 6787 seen32 candidatesComplete
Feb 6 → Jun 6878 seen53 candidatesComplete
Jun 6 → Jul 6211 seen15 candidatesComplete
Jul 6 → Aug 5184 seen2 candidatesComplete
Commit communication

Does the history explain itself?

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

64/100 average clarity
311Strong · 80–100
1054Adequate · 60–79
555Thin · 40–59
150Opaque · 0–39
20security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Mitchell Bagot640192109068
Tobin C. Harding4096544063
jrakibi944912068
Nick Johnson189204059
Andrew Poelstra512011075
Jamil Lambert, PhD114185061
Fmt Bot311412045
Trevor Arjeski111111069
Shing Him Ng3176056
Ismail Daif2263050
satsfy (Renato Britto)1766066
Martin Habovstiak2754069
Analysis record

Published AI watches

Last scanned 20 minutes ago

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 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 60 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

primitives: Bump version to 0.103.0

This commit is a routine release preparation: it bumps the version number of the `bitcoin-primitives` crate from 0.102.0 to 0.103.0, updates related dependency declarations in other crates, refreshes lock files, and adds a changelog entry.…

5612224dby Tobin C. Harding+48−88 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: bump version to 1.1.0

This commit is a routine version bump for the bitcoin_hashes crate from 1.0.0 to 1.1.0. It updates dependency references across the workspace, records the release in the changelog, and adjusts deprecation lint allowances in tests. There is…

bf3f25f4by Nick Johnson+34−269 files
No security note in commit
Informational 17 AI analysisMessage 80 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

refactor(bip32): Xpub child tweak api

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

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

refactor(bip32): rename Xpub and Xpriv derivation methods

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

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

internals: Bump version to 0.6.0

This commit is a routine version bump for the internal 'bitcoin-internals' crate from 0.5.0 to 0.6.0. It updates version numbers across package manifests and lock files, and adds a changelog describing API cleanups and small improvements. …

aed7a9ceby Tobin C. Harding+73−5616 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Remove hex dep from internals

This commit simply removes an unused software dependency (the hex-conservative crate) from the internals sub-package and updates related package configuration files. It is a routine cleanup change with no security relevance.

bd0d4bc0by Tobin C. Harding+8−118 files
No security note in commit
Informational 17 AI analysisMessage 73 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Replace external uses of base58 encoding with Base58CkString

This commit is a routine internal code cleanup in the rust-bitcoin project. It swaps old base58 encoding helper functions for a new equivalent type, Base58CkString, in three source files. There is no indication from the commit itself that …

No security-relevant signal in the diff: equivalent API swap onlyNo new dependencies or unsafe blocks introducedNo changes to input validation, parsing, or secret handling
7f5fbd13by Mitchell Bagot+10−103 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add try_push to Buffer trait

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

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

consensus_encoding: Rename _with decoder functions

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

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

Move ScriptPubKeyBufExt to addresses

This commit is a routine internal code reorganization in the rust-bitcoin library. It moves a helper trait (ScriptPubKeyBufExt) and its functions from one internal module to another, and re-exports it so existing users see no change. There…

ed00d91aby Mitchell Bagot+92−552 files
No security note in commit
Informational 16 AI analysisMessage 50 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: Deprecate sha256t_tag macro

This is a routine code-maintenance change: the developers are marking an old helper macro as deprecated and telling users how to write the same code by hand. There is no bug fix, no security patch, and no vulnerability being addressed in t…

ac921e97by jrakibi+26−123 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

2026-07-05 automated rustfmt nightly

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

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

hashes: implement sha256t::Tag without the macro

This commit is a routine code cleanup in the rust-bitcoin library. It replaces a macro used to define SHA-256 tagged hash identifiers with direct Rust code that does the same thing. The actual hash values and behavior are unchanged; only t…

0131814dby jrakibi+30−133 files
No security note in commit
Informational 15 AI analysisMessage 95 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

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

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

5f933d5cby satsfy (Renato Britto)+1−11 file
No security note in commit
Repository ledger

Explore captured commits

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

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

Remove PrivateKeyExt and make PrivateKey::as_inner private

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

Remove PrivateKeyExt trait and make PrivateKey::as_inner private.

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

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

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

refactor: remove DerivationError

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

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

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

refactor: split bip32 xkey parse errors

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

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

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

style: reorder bip32 error impls

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

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

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

Remove Encodable and Decodable impls for crate types

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

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

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

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

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

Replace uses of bitcoin::consensus with consensus_encoding

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

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

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

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

Replace uses of consensus in tests

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

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

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

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

Replace use of con_serde in sighash test

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

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

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

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

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

Add XOnlyPublicKey::verify

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

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

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

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

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

Move TapTweak trait to taproot-primitives

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

Move TapTweak trait to taproot-primitives.

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

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

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

Replace dyn fmt::Write with fmt::Formatter

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

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

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

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

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

Add tests to verify 0 return for overflow

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

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

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

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

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

Return 0 on Target::from_compact overflow

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

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

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

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

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

Clear pushnum cache on signature operations in sigop count

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

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

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

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

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

Move from_key_and_merkle_root back to taproot-primitives

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

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

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

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

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

refactor: split bip32 path parse errors

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

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

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

refactor: split bip32 derivation errors

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

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

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

Replace impl_to_hex_from_lower_hex with deprecated inherent to_hex

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

Replace impl_to_hex_from_lower_hex with deprecated inherent to_hex on
all types.

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

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

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

Move impl_array_newtype to include/array_newtype.rs

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

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

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

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

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

Add regression test for from_base64 bug

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

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

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

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

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

Use write! in UnknownAddressTypeError display

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

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

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

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

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

2026-06-14 automated rustfmt nightly

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

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

Security candidateAdd #[inline] to all trivial functions in cryptoby Mitchell Bagot · 2a1e1ffa · Jun 13, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · Mitchell Bagot

Add #[inline] to all trivial functions in crypto

All functions that are relatively trivial should be annotated with the
inline attribute to hint to the compiler to optimise them by inlining.

Add #[inline] to all small/trivial functions in crypto.

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 adds compiler hints (#[inline]) to small functions in the crypto module. It does not change any behavior, logic, or data handling. There is no security issue here.

Security candidateprimitives: Simplify and optimize witness decoderby jrakibi · 4e780508 · Jun 10, 2026 · 1 fileMessage 68 · AdequateModerate 68Details
Commit message · jrakibi

primitives: Simplify and optimize witness decoder

The current logic for the index space in witness decoder lets an
attacker allocate a claimed size without giving any input, which opens
the door to many DoS attacks, some of which we already handle.

But the current code still lets an attacker force a 16 MB allocation
with ~10 bytes of input.

The new logic pushes bytes blindly into `content` without building the
index space in `push_bytes()`, then in `end()` walks through `content`
to build the index space.

This simplifies the code, gives an important speedup, and avoids:

- the 16 MB up-front allocation we currently have for the index space
- `reserve_batch()` is no longer needed, along with the
`MIN_` and `MAX_VECTOR_ALLOCATE` constants

- we can drop the `cursor` field from the decoder
- the DoS vector where an attacker sends a few bytes to force a large
allocation, since the buffer only grows by the bytes actually received

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
explicit security language
AI analysis · Moderate 68/100

This commit fixes a denial-of-service (DoS) weakness in how the rust-bitcoin library decodes Bitcoin transaction witness data. Previously, an attacker could send only about 10 bytes of data and trick the decoder into reserving 16 MB of memory up front. The new code only allocates memory for bytes that have actually arrived, making memory-exhaustion attacks much harder. The commit also simplifies the code and removes several helper functions and constants.

Security candidatenetwork: Bump version to 1.0.0by Tobin C. Harding · 4d4a8d28 · Jun 9, 2026 · 8 filesMessage 68 · AdequateInformational 15Details
Commit message · Tobin C. Harding

network: Bump version to 1.0.0

In preparation for release add a changelog entry, bump the version
number, update local downstream crates, 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 the bitcoin-network-kind crate from version 0.1.0 to 1.0.0. It updates version numbers in package manifests, lock files, and a changelog, but does not change any source code or behavior. There is no security relevance.