Replace encode with checksum encoding in tests
What the developer wrote
Authored by Mitchell Bagot
Replace encode with checksum encoding in tests
The new Base58CkString type only performs base58check encoding, not the
non-checksum type encoding. As such, it has no replacement for the old
encode function. In order to confirm the same functionality (leading
zeros, >128 chars, etc), the uses of encode can be replaced by
equivalent base58check strings in the tests.
Replace encode usage in test cases with equivalent base58check encoded
strings and encoding calls.
What changed, and why it matters
This commit only changes test code in the rust-bitcoin base58 module. It replaces calls to an old plain base58 encoder with equivalent base58check-encoded strings and a new checksum-based encoder. There is no change to production code, no security fix, and no vulnerability.
No security action needed. Treat as a normal test-maintenance commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff updates unit tests in base58/src/lib.rs to use Base58CkString::encode_unbounded (base58check encoding) instead of the removed encode (plain base58 encoding). Expected output strings are updated to their base58check equivalents. The decode_check test for the too-short error is updated to use a literal base58check string. No runtime code is modified.
Changed components
base58/src/lib.rs testsInspect captured patch +12 / −12
diff --git a/base58/src/lib.rs b/base58/src/lib.rs
index f2d4ced1..0a365586 100644
--- a/base58/src/lib.rs
+++ b/base58/src/lib.rs
@@ -412,26 +412,26 @@ mod tests {
#[test]
fn base58_encode() {
// Basics
- assert_eq!(&encode(&[0][..]), "1");
- assert_eq!(&encode(&[1][..]), "2");
- assert_eq!(&encode(&[58][..]), "21");
- assert_eq!(&encode(&[13, 36][..]), "211");
+ assert_eq!(Base58CkString::encode_unbounded(&[13, 36][..]).as_str(), "7YY3x3vS");
// Leading zeroes
- assert_eq!(&encode(&[0, 13, 36][..]), "1211");
- assert_eq!(&encode(&[0, 0, 0, 0, 13, 36][..]), "1111211");
+ assert_eq!(Base58CkString::encode_unbounded(&[0, 13, 36][..]).as_str(), "17YZPJu4L");
+ assert_eq!(
+ Base58CkString::encode_unbounded(&[0, 0, 0, 0, 13, 36][..]).as_str(),
+ "11117YaXDHva"
+ );
// Long input (>128 bytes => has to use heap)
- let res = encode(
+ let res = Base58CkString::encode_unbounded(
"BitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBit\
coinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoinBitcoin"
.as_bytes(),
);
let exp =
- "ZqC5ZdfpZRi7fjA8hbhX5pEE96MdH9hEaC1YouxscPtbJF16qVWksHWR4wwvx7MotFcs2ChbJqK8KJ9X\
- wZznwWn1JFDhhTmGo9v6GjAVikzCsBWZehu7bm22xL8b5zBR5AsBygYRwbFJsNwNkjpyFuDKwmsUTKvkULCvucPJrN5\
- QUdxpGakhqkZFL7RU4yT";
- assert_eq!(&res, exp);
+ "4hqMa7U6Kxg4YstWo7KztyYAAkTuhuLWTvrHia8nrgx5eb2E8cf79wD9dBjd4c9STsTTXWZT5pp985vP\
+ nL4MVTQrt4EW5jgAk5Fh81PoF6jjhCyUZY2kZ8iYaM5XpfPkZ6aki57S6oiuVv4cmJz2ou8ssxEKNRJMWjSFL5izLbe\
+ s9rugAdBdrboyHMSAtSNY1Nrb4";
+ assert_eq!(res.as_str(), exp);
// Addresses
let addr = hex!("00f8917303bfa8ef24f292e8fa1419b20460ba064d");
@@ -472,7 +472,7 @@ mod tests {
// Check that empty slice passes roundtrip.
assert_eq!(decode_check(Base58CkString::encode_unbounded(&[]).as_str()), Ok(vec![]));
// Check that `len > 4` is enforced.
- assert_eq!(decode_check(&encode(&[1, 2, 3])), Err(TooShortError { length: 3 }.into()));
+ assert_eq!(decode_check("Ldp"), Err(TooShortError { length: 3 }.into()));
}
}
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.