CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

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

RB0f68fcb3 View source ↗
Public commit record

What the developer wrote

Authored by Andrew Poelstra

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

8899dfd242cf418ee6ce3f05e5828e8579af9f3c release bitcoin_hashes 1.2.0 (Andrew Poelstra)
44552e3ad3035e1001b665bfd4dd3511042cd1f2 hashes: update API files (Andrew Poelstra)
7d8f06d256152a3de1ec9b54e3dd643271983f0d hashes: add several methods to sha256::Midstate for computing them in const contexts (Andrew Poelstra)
dc21841b46abc39c49ed7075131f1ac46416137f hashes: add sha256::Midstate::SHA256_IV constant (Andrew Poelstra)

Pull request description:

Adds a new `Midstate::SHA256_IV` constant which allows you to construct a midstate equivalent to a new empty sha256 engine. Then adds `update` methods to `Midstate` which allow you to "ratchet forward" arbitrary midstates, 64 bytes at a time, by hashing the data. There is one fast method and two slow constfn methods.

The motivation is that in Elements we have many Merkle roots which are computed using sha256 midstates, which is safe to do because we're using domain-separated hashes and because our internal nodes are always hashes of exactly 64 bytes of data, which do not not need any length-suffixing. In rust-simplicity we have several such Merkle root types, many of which have a huge pile of precomputed constants, but whose constructors are forced to be non-`const`, which limits their use in generic contexts.

It's maybe a bit uncouth for me to just add some methods I need and cut a new release in a 1.x crate, but

* we have taken great pains to keep `hashes` out of other crates' public APIs, so its stability is not as paramount as it would be for encoding or units, say
* all the new methods (and one constant) are on the `Midstate` type, which is a "don't touch this unless you are a cryptographer" part of the API and already has some ugly methods
* the additions seem pretty reasonable to me, assuming you accept that we have a `Midstate` type at all; essentially they generalize the already-existing `hash_tag` method
* I am BDFL of this project


ACKs for top commit:
tcharding:
ACK 8899dfd242cf418ee6ce3f05e5828e8579af9f3c


Tree-SHA512: 031cb5b384dd5ccf4b0878984735e58ec3cae947b7fcae3c892bb99991ac1843e55c2e33395ede71f2016f4cd2f589263d9d8ec656bd48ff938130763893910b
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

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 security bug, fix, or vulnerability. The change expands the public API surface slightly, which is normal for a library release.

Recommended action

No security action required. Treat as a normal dependency/API update; review downstream usage of the new Midstate methods only if your project exposes SHA-256 midstates to untrusted input.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 2/15
Confidence 9/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from rust-bitcoin

Related watches

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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗