What the developer wrote
Authored by Abeeujah
Use BlockEncoder for Block encoding
Block has a BlockEncoder newtype for consensus encoding Block
objects, but the Encode implementation currently uses a bare
Encoder3.
This fails to properly encapsulate the inner state of the
Block type and its encoding behavior. Switch the implementation
to use BlockEncoder.
What changed, and why it matters
This is a small internal code cleanup in the rust-bitcoin library. It changes how Bitcoin block objects are encoded to use a dedicated BlockEncoder wrapper instead of a generic two-part encoder. The actual bytes produced are unchanged; only the internal type structure is different. There is no security issue visible in the change.
No security action needed. Treat as normal refactoring/code-quality review.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit refactors the consensus Encode implementation for Block in primitives/src/block.rs. Previously the associated Encoder type was an ad-hoc Encoder2
Changed components
primitives/src/block.rsBlock consensus encodingInspect captured patch +3 / −3
diff --git a/primitives/src/block.rs b/primitives/src/block.rs
index df3dfea1..4910bc37 100644
--- a/primitives/src/block.rs
+++ b/primitives/src/block.rs
@@ -327,18 +327,18 @@ where
V: Validation,
{
type Encoder<'e>
- = Encoder2<HeaderEncoder<'e>, Encoder2<CompactSizeEncoder, SliceEncoder<'e, Transaction>>>
+ = BlockEncoder<'e>
where
Self: 'e;
fn encoder(&self) -> Self::Encoder<'_> {
- Encoder2::new(
+ BlockEncoder::new(Encoder2::new(
self.header.encoder(),
Encoder2::new(
CompactSizeEncoder::new(self.transactions.len()),
SliceEncoder::without_length_prefix(&self.transactions),
),
- )
+ ))
}
}
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.