merge queue: embarking main (c103c2d) and [#9141 + #9153 + #9140] together

.github/ISSUE_TEMPLATE/usability_testing_plan.md

@@ -31,7 +31,7 @@ assignees: ''
 
 ### Method
 
-<!-- Explain whether the tests will be co-located or reomte, moderated or unmoderated, and who will attend the sessions (e.g a moderator and a note-taker) -->
+<!-- Explain whether the tests will be co-located or remote, moderated or unmoderated, and who will attend the sessions (e.g a moderator and a note-taker) -->
 
 ### Test environment, equipment and logistics
 
@@ -56,7 +56,7 @@ assignees: ''
 
 ## Session Outline and timing
 
-<!-- The following sections provide some space to plan out the script and and tasks for your participants -->
+<!-- The following sections provide some space to plan out the script and tasks for your participants -->
 
 ### 1.Introduction to the session (5\')
 

Cargo.lock

@@ -1664,9 +1664,9 @@ dependencies = [
 
 [[package]]
 name = "hashbrown"
-version = "0.15.0"
+version = "0.15.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "1e087f84d4f86bf4b218b927129862374b72199ae7d8657835f1e89000eea4fb"
+checksum = "bf151400ff0baff5465007dd2f3e717f3fe502074ca563069ce3a6629d07b289"
 dependencies = [
  "foldhash",
 ]
@@ -2006,7 +2006,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "62f822373a4fe84d4bb149bf54e584a7f4abec90e072ed49cda0edea5b95471f"
 dependencies = [
  "equivalent",
- "hashbrown 0.15.0",
+ "hashbrown 0.15.2",
  "serde",
 ]
 
@@ -2477,7 +2477,7 @@ checksum = "15b482df36c13dd1869d73d14d28cd4855fbd6cfc32294bee109908a9f4a4ed7"
 dependencies = [
  "crossbeam-epoch",
  "crossbeam-utils",
- "hashbrown 0.15.0",
+ "hashbrown 0.15.2",
  "metrics",
  "quanta",
  "sketches-ddsketch",

book/src/dev/rfcs/0000-template.md

@@ -122,7 +122,7 @@ Think about what the natural extension and evolution of your proposal would
 be and how it would affect Zebra and Zcash as a whole. Try to use this
 section as a tool to more fully consider all possible
 interactions with the project and cryptocurrency ecosystem in your proposal.
-Also consider how the this all fits into the roadmap for the project
+Also consider how this all fits into the roadmap for the project
 and of the relevant sub-team.
 
 This is also a good place to "dump ideas", if they are out of scope for the

book/src/dev/rfcs/0006-contextual-difficulty.md

@@ -421,7 +421,7 @@
 Since the `PoWLimit`s are `2^251 − 1` for Testnet, and `2^243 − 1` for Mainnet,
 the sum of these difficulty thresholds will be less than or equal to
 `(2^251 − 1)*17 = 2^255 + 2^251 - 17`. Therefore, this calculation can not
-overflow a `u256` value. So the function is infalliable.
+overflow a `u256` value. So the function is infallible.
 
 In Zebra, contextual validation starts after Canopy activation, so we can assume
 that the relevant chain contains at least 17 blocks. Therefore, the `PoWLimit`
@@ -499,7 +499,7 @@
 * there is always an odd number of blocks in `MedianTime()`, so the median is
   always the exact middle of the sequence.
 
-Therefore, the function is infalliable.
+Therefore, the function is infallible.
 
 ### Test network minimum difficulty calculation
 [test-net-min-difficulty-calculation]: #test-net-min-difficulty-calculation
@@ -580,7 +580,7 @@
 Zebra, contextual validation starts after Canopy activation. So we can assume
 that there is always a previous block.
 
-Therefore, this function is infalliable.
+Therefore, this function is infallible.
 
 ### Block difficulty threshold calculation
 [block-difficulty-threshold-calculation]: #block-difficulty-threshold-calculation
@@ -647,7 +647,7 @@
 division by `AveragingWindowTimespan`. Performing the multiplication first
 could overflow.
 
-If implemented in this way, the function is infalliable.
+If implemented in this way, the function is infallible.
 
 `zcashd` truncates the `MeanTarget` after the mean calculation, and
 after dividing by `AveragingWindowTimespan`. But as long as there is no overflow,
@@ -753,10 +753,10 @@
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
 ## Re-using the relevant chain API in other contextual checks
 [relevant-chain-api-reuse]: #relevant-chain-api-reuse
 
 The relevant chain iterator can be re-used to implement other contextual
 validation checks.
 
 For example, responding to peer requests for block locators, which means

book/src/dev/rfcs/0009-zebra-client.md

@@ -341,7 +341,7 @@ endpoint
 <!-- be and how it would affect Zebra and Zcash as a whole. Try to use this -->
 <!-- section as a tool to more fully consider all possible -->
 <!-- interactions with the project and cryptocurrency ecosystem in your proposal. -->
-<!-- Also consider how the this all fits into the roadmap for the project -->
+<!-- Also consider how this all fits into the roadmap for the project -->
 <!-- and of the relevant sub-team. -->
 
 <!-- This is also a good place to "dump ideas", if they are out of scope for the -->

book/src/dev/rfcs/drafts/xxxx-basic-integration-testing.md

@@ -124,7 +124,7 @@ Think about what the natural extension and evolution of your proposal would
 be and how it would affect Zebra and Zcash as a whole. Try to use this
 section as a tool to more fully consider all possible
 interactions with the project and cryptocurrency ecosystem in your proposal.
-Also consider how the this all fits into the roadmap for the project
+Also consider how this all fits into the roadmap for the project
 and of the relevant sub-team.
 
 This is also a good place to "dump ideas", if they are out of scope for the

zebra-chain/src/amount.rs

@@ -416,7 +416,7 @@ where
     }
 }
 
-// TODO: add infalliable impls for NonNegative <-> NegativeOrZero,
+// TODO: add infallible impls for NonNegative <-> NegativeOrZero,
 //       when Rust uses trait output types to disambiguate overlapping impls.
 impl<C> std::ops::Neg for Amount<C>
 where

zebra-chain/src/amount/tests/vectors.rs

@@ -180,12 +180,12 @@ fn deserialize_checks_bounds() -> Result<()> {
     let mut big_bytes = Vec::new();
     (&mut big_bytes)
         .write_u64::<LittleEndian>(big)
-        .expect("unexpected serialization failure: vec should be infalliable");
+        .expect("unexpected serialization failure: vec should be infallible");
 
     let mut neg_bytes = Vec::new();
     (&mut neg_bytes)
         .write_i64::<LittleEndian>(neg)
-        .expect("unexpected serialization failure: vec should be infalliable");
+        .expect("unexpected serialization failure: vec should be infallible");
 
     Amount::<NonNegative>::zcash_deserialize(big_bytes.as_slice())
         .expect_err("deserialization should reject too large values");

zebra-network/src/address_book.rs

@@ -265,7 +265,7 @@ impl AddressBook {
     /// Get the active addresses in `self` in random order with sanitized timestamps,
     /// including our local listener address.
     ///
-    /// Limited to a the number of peer addresses Zebra should give out per `GetAddr` request.
+    /// Limited to the number of peer addresses Zebra should give out per `GetAddr` request.
     pub fn fresh_get_addr_response(&self) -> Vec<MetaAddr> {
         let now = Utc::now();
         let mut peers = self.sanitized(now);

zebrad/tests/common/get_block_template_rpcs/get_block_template.rs

@@ -34,7 +34,7 @@ use crate::common::{
 /// This ensures that a new template can be deserialized and sent to interrupt the
 /// block proposal requests if the old template is no longer valid in edge-cases where
 /// an old template becomes invalid right after it's returned. We've seen the getblocktemplate
-/// respond within ~50ms of a request locallly, and this test is run on GCP compute instances
+/// respond within ~50ms of a request locally, and this test is run on GCP compute instances
 /// that should offer comparable latency in CI.
 pub const EXTRA_LONGPOLL_WAIT_TIME: Duration = Duration::from_millis(150);