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

Merge rust-bitcoin/rust-bitcoin#6906: consensus_encoding, primitives: expose exact encoding size for block and transaction

Public commit record

What the developer wrote

Authored by Andrew Poelstra

100/100 · Strong
Merge rust-bitcoin/rust-bitcoin#6906: consensus_encoding, primitives: expose exact encoding size for block and transaction

0ac85705e849c7a44a730f6f2a41c6f0d069e42b primitives: make transaction and block exact encodable (Nick Johnson)
95b2d374f7a48e30a951722df7e6120b660f0d18 primitives: refactor handrolled witness encoder iterator (Nick Johnson)
50e81ce80404dd1d89557b0f2ea51e765e260eb4 consensus_encoding: add ExactSizeEncoder implementations to iterators (Nick Johnson)

Pull request description:

It is helpful in higher level protocols like PSBT to be able to get the serialized size of a type for things like length prefixes. To expose this on the top of the hierarchy `Block` and `Transaction` types, the lower level iterator needs to support exact size calculations (for stuff like inputs and outputs). A small code change, however, I think this is the first non-constant time exact size implementations due to iterator's dynamic size. I think it is worth it.


ACKs for top commit:
apoelstra:
ACK 0ac85705e849c7a44a730f6f2a41c6f0d069e42b; successfully ran local tests
tcharding:
ACK 0ac85705e849c7a44a730f6f2a41c6f0d069e42b


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

What changed, and why it matters

This commit adds a way to ask, in advance, exactly how many bytes a Bitcoin block or transaction will take when serialized. It is a feature addition for the library's encoding system, not a fix for a vulnerability. There is no indication it addresses a security bug or was triggered by a security report.

Recommended action

No security action required. Treat as a normal feature/API enhancement. Reviewers may optionally verify that the new len() implementations correctly account for all bytes (including length prefixes) and do not introduce panics on large collections, but this is code-quality rather than security.

Security signals we found

01

No security-relevant signals in commit message or diff

02

Feature addition: expose exact encoded size

03

No mention of vulnerability, CVE, bug bounty, or security report

04

No bounds/overflow/underflow fixes observed

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/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.