consensus_encoding: update package docs for consensus encoding clarity
What changed, and why it matters
This commit only rewrites the user-facing documentation comments in a single Rust source file. It clarifies how the consensus encoding library works and reorganizes the description of provided functions. No program logic, APIs, or security behavior changed.
No security action needed; treat as a normal documentation update.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is limited to doc comments in consensus_encoding/src/lib.rs. It rephrases explanations of the sans-I/O design, deterministic encoding guarantee, Encode/Decode traits, driver functions, and feature flags. There are no code, type signature, dependency, or configuration changes.
Changed components
consensus_encoding/src/lib.rs documentation onlyInspect captured patch +22 / −18
diff --git a/consensus_encoding/src/lib.rs b/consensus_encoding/src/lib.rs
index 20b87a11..a2655f1b 100644
--- a/consensus_encoding/src/lib.rs
+++ b/consensus_encoding/src/lib.rs
@@ -2,30 +2,31 @@
//! # Rust Bitcoin Consensus Encoding
//!
-//! Traits and utilities for encoding and decoding Bitcoin data types in a consensus-consistent way,
-//! using a *sans-I/O* architecture.
+//! Traits and utilities for encoding and decoding Bitcoin data types using a *sans-I/O*
+//! architecture.
//!
//! Rather than reading from or writing to [`std::io::Read`]/[`std::io::Write`] traits directly, the
//! codec types work with byte slices. This keeps codec logic I/O-agnostic, so the same
//! implementation works in `no_std` environments, sync I/O, async I/O, and hash engines without
//! duplicating logic or surfacing I/O errors in non-I/O contexts (e.g. when hashing an encoding).
+//! This crate only supports deterministic encoding and will never support types like floats whose
+//! encoding is non-deterministic or platform-dependent.
//!
//! *Consensus* encoding is the canonical byte representation of Bitcoin data types used across the
-//! peer-to-peer network and transaction serialization. This crate only supports deterministic
-//! encoding and will never support types like floats whose encoding is non-deterministic or
-//! platform-dependent.
+//! peer-to-peer network and transaction serialization. Bitcoin types which support consensus
+//! encoding implement the [`Encode`] and [`Decode`] traits.
//!
//! # Encoding
//!
-//! Types implement [`Encode`] to produce an [`Encoder`], which yields encoded bytes in chunks
-//! via [`Encoder::current_chunk`] and [`Encoder::advance`]. The caller drives the process by
-//! pulling chunks until `advance` returns [`EncoderStatus::Finished`].
+//! Consensus encodable types implement [`Encode`] to produce an [`Encoder`], which yields encoded
+//! bytes in chunks via [`Encoder::current_chunk`] and [`Encoder::advance`]. The caller drives the
+//! process by pulling chunks until `advance` returns [`EncoderStatus::Finished`].
//!
//! # Decoding
//!
-//! Types implement [`Decode`] to produce a [`Decoder`], which consumes bytes via
-//! [`Decoder::push_bytes`] until it signals completion by returning `Ok(DecoderStatus::Ready)`. The
-//! caller then calls [`Decoder::end`] to obtain the decoded value.
+//! Consensus encodable types implement [`Decode`] to produce a [`Decoder`], which consumes bytes
+//! via [`Decoder::push_bytes`] until it signals completion by returning `Ok(DecoderStatus::Ready)`.
+//! The caller then calls [`Decoder::end`] to obtain the decoded value.
//!
//! Unlike encoding, decoding is fallible. Both `push_bytes` and `end` return `Result`. I/O errors
//! are handled by the caller, keeping the codec logic I/O-agnostic.
@@ -33,7 +34,8 @@
//! # Drivers
//!
//! This crate provides free functions which drive codecs for common I/O interfaces. On the decoding
-//! side we provide:
+//! side we provide functions which take a consensus encodable type parameter `T: Decode` to select
+//! the output type's associated decoder.
//!
//! * [`decode_from_read`]: Decode from a stdlib buffered reader.
//! * [`decode_from_read_unbuffered`]: Decode from a stdlib unbuffered reader (4k buffer on stack).
@@ -42,22 +44,24 @@
//! * [`decode_from_slice_unbounded`]: Slice can contain additional data after decoding completes.
//! * [`decode_from_hex`]: Decode from a hex string without heap allocations.
//!
-//! Each function above takes a type parameter `T: Decode` to select the output type and its
-//! associated decoder. The following variants instead accept a [`Decoder`] type directly,
-//! instantiated with [`Default`], and can be used when the output type does not implement [`Decode`]:
+//! The following variants instead accept an agnostic [`Decoder`] type directly, instantiated with
+//! [`Default`], and can be used when the output type does not implement [`Decode`]:
//!
//! * [`decode_from_read_with_decoder`]: Counterpart to [`decode_from_read`].
//! * [`decode_from_slice_with_decoder`]: Counterpart to [`decode_from_slice`].
//! * [`decode_from_slice_unbounded_with_decoder`]: Counterpart to [`decode_from_slice_unbounded`].
//! * [`decode_from_hex_with_decoder`]: Counterpart to [`decode_from_hex`].
//!
-//! And on the encoding side we provide:
+//! And on the encoding side we provide similar functions for consensus encodable types.
//!
//! * [`encode_to_writer`]: Encode to a stdlib writer.
-//! * [`drain_to_writer`]: Drain an encoder to a stdlib writer.
//! * [`encode_to_vec`]: Encode to the heap.
-//! * [`drain_to_vec`]: Drain an encoder to the heap.
//! * [`encode_to_hex`]: Encode to a hex string.
+//!
+//! As well as variants for agnostic [`Encoder`] types.
+//!
+//! * [`drain_to_writer`]: Drain an encoder to a stdlib writer.
+//! * [`drain_to_vec`]: Drain an encoder to the heap.
//! * [`drain_to_hex`]: Drain an encoder to a hex string.
//!
//! # Feature Flags
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.