chore: fix typos

README.md

@@ -13,30 +13,31 @@ Modern, minimalistic & standard-compliant wallet-level libraries: an alternative
 to `rust-bitcoin` and BDK libraries from [LNP/BP Standards Association][Assoc].
 
 The main goals of the libraries are:
+
 - **fast stabilization of APIs**: the library will be targeting v1.0 version
   within the first year of its development; which should enable downstream
   crates using the library also to stabilize and not spend too much effort
-  on changing the integration each time the new version of `bp-wallet` is 
+  on changing the integration each time the new version of `bp-wallet` is
   released;
-- **no use of private keys**: the library analyzes wallet state using 
-  descriptors and allows to produce unsigned PSBTs, as well as publish and 
-  analyze (partially) signed PSBTs - but doesn't provide a signer or a way to 
+- **no use of private keys**: the library analyzes wallet state using
+  descriptors and allows to produce unsigned PSBTs, as well as publish and
+  analyze (partially) signed PSBTs - but doesn't provide a signer or a way to
   work with any private key material (seeds, mnemonics, xprivs, private keys);
   PSBT files must be signed with some external signers or hardware wallets;
 - **standard-compliance**: the library tries to provide full compliance with
-  existing bitcoin standards defined in BIPs and do not use any legacy 
-  approaches or "blockchain-not-bitcoin" practices (like the ones provided by 
+  existing bitcoin standards defined in BIPs and do not use any legacy
+  approaches or "blockchain-not-bitcoin" practices (like the ones provided by
   BLIPs);
 - **separation of bitcoin consensus and standards**: the consensus-related
   code is not a part of this library; all data structures and business logic
   which may have consensus meaning and is required for a wallet is separated
   into an independent [`bp-primitives`] library (a part of [`bp-core`] library),
-  which is planned to be more extensively audited and ossified alongside 
+  which is planned to be more extensively audited and ossified alongside
   bitcoin protocol (while this library will continue to evolve with better
   APIs and to match new wallet standards);
-- **extensive use of descriptors**: library focuses on defining all parts of 
+- **extensive use of descriptors**: library focuses on defining all parts of
   a wallet using descriptors; additionally to script pubkey descriptors it also
-  supports xpub descriptors, derivation descriptors, applied to script pubkey 
+  supports xpub descriptors, derivation descriptors, applied to script pubkey
   descriptor as a whole, and input descriptors for RBFs. You can read more on
   specific descriptor types in the [section below](#descriptors);
 - **script templates**: the library allows to provide an arbitrary script as
@@ -49,8 +50,8 @@ The main goals of the libraries are:
 - **APIs usable in all rust projects and in FFI**: the library doesn't use
   async rust, complex callbacks, threads etc., which allows to keep the API
   simple, usable from any rust app (like ones using reactive patterns instead of
-  async); at the same time all the data structures of the library are 
-  `Send + Sync`, meaning that they can be used in any multi-thread or async 
+  async); at the same time all the data structures of the library are
+  `Send + Sync`, meaning that they can be used in any multi-thread or async
   environment;
 - **abstracted blockchain data providers**: the library abstracts blockchain
   indexer APIs (Electrum, Esplora, Bitcoin Core etc.) and also provides their
@@ -61,51 +62,52 @@ The main goals of the libraries are:
 ### Why not use `rust-bitcoin`?
 
 The library doesn't rely on `rust-bitcoin` crate. The reasons for that are:
-- **to keep the functionality set small and wallet-specific**: `rust-bitcoin` 
+
+- **to keep the functionality set small and wallet-specific**: `rust-bitcoin`
   provides "all in one" solution, covering many parts of bitcoin ecosystem, like
   bitcoin peer-to-peer protocol, not really used by a wallet;
 - **to keep API stable**: `rust-bitcoin` with each release significantly breaks
-  APIs, being in constant refactoring since early 2022 - a process likely to 
+  APIs, being in constant refactoring since early 2022 - a process likely to
   last for few years more; update of wallet libraries after each major change is
   painful and takes a lot of developers time and effort, as well as introduces
-  API breaking changes downstream preventing all dependent libraries from 
+  API breaking changes downstream preventing all dependent libraries from
   stabilization;
 - **separation of private key material**: in Rust it is impossible to achieve
   constant-time production of secret key material, as well as prevent the
   compiler from copying it all over the machine memory (`zeroise` and other
   approaches doesn't prevent that). Thus, providing secret keys alongside
   other APIs may lead to non-secure design of the wallet and should be avoided;
 - **separation of consensus code from standards**: `rust-bitcoin` provides next
-  to each other consensus-related structures and higher level wallet 
+  to each other consensus-related structures and higher level wallet
   abstractions, which contradicts to the design decision we are making in this
   library;
-- **to introduce strong semantic typing**: for instance, `rust-bitcoin` doesn't 
+- **to introduce strong semantic typing**: for instance, `rust-bitcoin` doesn't
   differentiate different forms of scripts (pubkey, sig, witness etc.), while
   in this library we are using semantic type approach, providing type-safe
   variants for each semantically-distinct entity even if it shares the same
   representation with others.
 
 As one may see from the list, `rust-bitcoin` design and maintenance approach
-contradicts to the major aims of this project - in fact, this project was 
-created by [Maxim Orlovsky][orlovsky] (who was the most active contributor to 
+contradicts to the major aims of this project - in fact, this project was
+created by [Maxim Orlovsky][orlovsky] (who was the most active contributor to
 `rust-bitcoin` since Q1 2019 till Q2 2022) in order to address these issues
-using different set of trade-offs, providing an alternative to `rust-bitcoin` 
+using different set of trade-offs, providing an alternative to `rust-bitcoin`
 to those who needs it.
 
 ### Why not use miniscript?
 
 Miniscript is great for many purposes, but it can't be used for many cases,
 including representation of BOLT-3 lightning channel transaction outputs,
-re-use of public key in different branches of pre-taproot scripts [1][ms-1]. 
-Miniscript is also still unstable, having recent changes to the semantic due 
+re-use of public key in different branches of pre-taproot scripts [1][ms-1].
+Miniscript is also still unstable, having recent changes to the semantic due
 to discovered bugs [2][ms-2] [3][ms-3]; meaning that the descriptors created
-with miniscript before may not be able to deterministically reproduce the 
-structure of some wallet UTXOs in a future. Finally, the existing Rust 
+with miniscript before may not be able to deterministically reproduce the
+structure of some wallet UTXOs in a future. Finally, the existing Rust
 miniscript implementation [`rust-miniscript`] inherits all `rust-bitcoin`
 tradeoffs, and is much more unstable in terms of APIs and semantic. Thus, it was
 decided to use this library to provide an alternative to miniscript with
-introduction of [script tempaltes][#script-templates] convertable to and from 
-miniscript representation - but with some externally-provided tools instead 
+introduction of [script templates][#script-templates] convertible to and from
+miniscript representation - but with some externally-provided tools instead
 of adding miniscript as a direct dependency here.
 
 ### Why not BDK?
@@ -116,28 +118,25 @@ Since we try to address those trade-offs, we had to create a BDK alternative.
 
 ### How this project is related to `descriptor-wallet`?
 
-[Descriptor wallet][descriptor-wallet] was an earlier project by the same 
+[Descriptor wallet][descriptor-wallet] was an earlier project by the same
 authors trying to address `rust-bitcoin` issues by building on top of it. With
-the recent v0.30 `rust-bitcoin` release it became clear that the effort of 
-adoption to API-breaking changes is much higher than creating a new independent 
-project from scratch, while at the same time the new project may address 
-`rust-bitcoin` issues in much more efficient and elegant way. Thus, it was 
+the recent v0.30 `rust-bitcoin` release it became clear that the effort of
+adoption to API-breaking changes is much higher than creating a new independent
+project from scratch, while at the same time the new project may address
+`rust-bitcoin` issues in much more efficient and elegant way. Thus, it was
 decided to discontinue `descriptor-wallet` and start the new `bp-wallet` project
 instead.
 
-
 ## Design
 
 ### Script templates
 
 ### Descriptors
 
-
 ## Contributing
 
 Contribution guidelines can be found in [CONTRIBUTING](CONTRIBUTING.md)
 
-
 ## More information
 
 ### MSRV
@@ -156,7 +155,11 @@ The libraries are distributed on the terms of Apache 2.0 opensource license.
 See [LICENCE](LICENSE) file for the license details.
 
 [Assoc]: https://lnp-bp.org
+
 [bp-primitives]: https://crates.io/crates/bp-primitives
+
 [bp-core]: https://github.com/BP-WG/bp-core
+
 [orlovsky]: https://github.com/dr-orlovsky
+
 [descriptor-wallet]: https://github.com/BP-WG/descriptor-wallet

SECURITY.md

@@ -1,10 +1,10 @@
 # Security
 
-We take the security of our software products and services seriously, which 
+We take the security of our software products and services seriously, which
 includes all source code repositories managed through our GitHub organizations.
 
-If you believe you have found a security vulnerability in any of our repository 
-that meets [definition of a security vulnerability][definition], please report 
+If you believe you have found a security vulnerability in any of our repository
+that meets [definition of a security vulnerability][definition], please report
 it to us as described below.
 
 ## Reporting Security Issues
@@ -14,8 +14,8 @@ it to us as described below.
 Instead, please report them to the repository maintainers by sending a **GPG
 encrypted e-mail** to _all maintainers of a specific repo_ using their GPG keys.
 
-A list of repository maintainers and their keys and e-mail addresses are 
-provided inside MAINTANERS.md file and MANIFEST.yml, with the latter also 
+A list of repository maintainers and their keys and e-mail addresses are
+provided inside MAINTAINERS.md file and MANIFEST.yml, with the latter also
 included in the README.md as a manifest block, which looks in the following way:
 
 ```yaml
@@ -30,11 +30,11 @@ Maintainers:
     ...
 ```
 
-You should receive a response within 72 hours. If for some reason you do not, 
-please follow up via email to ensure we received your original message. 
+You should receive a response within 72 hours. If for some reason you do not,
+please follow up via email to ensure we received your original message.
 
-Please include the requested information listed below (as much as you can 
-provide) to help us better understand the nature and scope of the possible 
+Please include the requested information listed below (as much as you can
+provide) to help us better understand the nature and scope of the possible
 issue:
 
 * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
@@ -56,4 +56,5 @@ We prefer all communications to be in English.
 We follow the principle of [Coordinated Vulnerability Disclosure][disclosure].
 
 [definition]: https://aka.ms/opensource/security/definition
+
 [disclosure]: https://aka.ms/opensource/security/cvd

_typos.toml

@@ -0,0 +1,7 @@
+[files]
+# exclude the directory "stl/"
+extend-exclude = ["stl/"]
+
+[default.extend-words]
+# Don't correct the name "Jon Atack".
+Atack = "Atack"

derive/src/taptree.rs

@@ -39,24 +39,24 @@ pub enum InvalidTree {
     Unfinalized(UnfinalizedTree),
 
     #[from(FinalizedTree)]
-    #[display("tap tree contains too many script leafs which doesn't fit a single Merkle tree")]
+    #[display("tap tree contains too many script leaves which doesn't fit a single Merkle tree")]
     MountainRange,
 }
 
 #[derive(Copy, Clone, Eq, PartialEq, Hash, Debug, Display, Error)]
-#[display("can't add more leafs to an already finalized tap tree")]
+#[display("can't add more leaves to an already finalized tap tree")]
 pub struct FinalizedTree;
 
 #[derive(Copy, Clone, Eq, PartialEq, Hash, Debug, Display, Error)]
 #[display(
-    "unfinalized tap tree containing leafs at level {0} which can't commit into a single Merkle \
+    "unfinalized tap tree containing leaves at level {0} which can't commit into a single Merkle \
      root"
 )]
 pub struct UnfinalizedTree(pub u7);
 
 #[derive(Clone, Eq, PartialEq, Debug, Default)]
 pub struct TapTreeBuilder {
-    leafs: Vec<LeafInfo>,
+    leaves: Vec<LeafInfo>,
     buoy: MerkleBuoy<u7>,
     finalized: bool,
 }
@@ -66,7 +66,7 @@ impl TapTreeBuilder {
 
     pub fn with_capacity(capacity: usize) -> Self {
         Self {
-            leafs: Vec::with_capacity(capacity),
+            leaves: Vec::with_capacity(capacity),
             buoy: zero!(),
             finalized: false,
         }
@@ -79,7 +79,7 @@ impl TapTreeBuilder {
             return Err(FinalizedTree);
         }
         let depth = leaf.depth;
-        self.leafs.push(leaf);
+        self.leaves.push(leaf);
         self.buoy.push(depth);
         if self.buoy.level() == u7::ZERO {
             self.finalized = true
@@ -91,7 +91,7 @@ impl TapTreeBuilder {
         if !self.finalized {
             return Err(UnfinalizedTree(self.buoy.level()));
         }
-        Ok(TapTree(self.leafs))
+        Ok(TapTree(self.leaves))
     }
 }
 
@@ -127,9 +127,9 @@ impl TapTree {
         }])
     }
 
-    pub fn from_leafs(leafs: impl IntoIterator<Item = LeafInfo>) -> Result<Self, InvalidTree> {
+    pub fn from_leaves(leaves: impl IntoIterator<Item = LeafInfo>) -> Result<Self, InvalidTree> {
         let mut builder = TapTreeBuilder::new();
-        for leaf in leafs {
+        for leaf in leaves {
             builder.push_leaf(leaf)?;
         }
         builder.finish().map_err(InvalidTree::from)

invoice/src/address.rs

@@ -384,7 +384,7 @@ pub enum AddressType {
     #[display("P2WPKH")]
     P2wpkh,
 
-    /// Pay-to-witness script pash
+    /// Pay-to-witness script hash
     #[display("P2WSH")]
     P2wsh,
 

psbt/src/coders.rs

@@ -893,7 +893,7 @@ impl Decode for TapTree {
                     .map_err(|_| PsbtError::InvalidTapLeafScriptSize(len))?,
             });
         }
-        TapTree::from_leafs(path).map_err(DecodeError::from)
+        TapTree::from_leaves(path).map_err(DecodeError::from)
     }
 }
 

psbt/src/keys.rs

@@ -285,7 +285,7 @@ pub enum InputKey {
     RequiredTimeLock,
 
     /// `PSBT_IN_REQUIRED_HEIGHT_LOCKTIME`
-    RequiredHeighLock,
+    RequiredHeightLock,
 
     /// `PSBT_IN_TAP_KEY_SIG`
     TapKeySig,
@@ -332,7 +332,7 @@ impl KeyType for InputKey {
         Self::OutputIndex,
         Self::Sequence,
         Self::RequiredTimeLock,
-        Self::RequiredHeighLock,
+        Self::RequiredHeightLock,
         Self::TapKeySig,
         Self::TapScriptSig,
         Self::TapLeafScript,
@@ -364,7 +364,7 @@ impl KeyType for InputKey {
             x if x == Self::OutputIndex.into_u8() => Self::OutputIndex,
             x if x == Self::Sequence.into_u8() => Self::Sequence,
             x if x == Self::RequiredTimeLock.into_u8() => Self::RequiredTimeLock,
-            x if x == Self::RequiredHeighLock.into_u8() => Self::RequiredHeighLock,
+            x if x == Self::RequiredHeightLock.into_u8() => Self::RequiredHeightLock,
             x if x == Self::TapKeySig.into_u8() => Self::TapKeySig,
             x if x == Self::TapScriptSig.into_u8() => Self::TapScriptSig,
             x if x == Self::TapLeafScript.into_u8() => Self::TapLeafScript,
@@ -396,7 +396,7 @@ impl KeyType for InputKey {
             InputKey::OutputIndex => PSBT_IN_OUTPUT_INDEX,
             InputKey::Sequence => PSBT_IN_SEQUENCE,
             InputKey::RequiredTimeLock => PSBT_IN_REQUIRED_TIME_LOCKTIME,
-            InputKey::RequiredHeighLock => PSBT_IN_REQUIRED_HEIGHT_LOCKTIME,
+            InputKey::RequiredHeightLock => PSBT_IN_REQUIRED_HEIGHT_LOCKTIME,
             InputKey::TapKeySig => PSBT_IN_TAP_KEY_SIG,
             InputKey::TapScriptSig => PSBT_IN_TAP_SCRIPT_SIG,
             InputKey::TapLeafScript => PSBT_IN_TAP_LEAF_SCRIPT,
@@ -430,7 +430,7 @@ impl KeyType for InputKey {
             InputKey::OutputIndex => false,
             InputKey::Sequence => false,
             InputKey::RequiredTimeLock => false,
-            InputKey::RequiredHeighLock => false,
+            InputKey::RequiredHeightLock => false,
 
             InputKey::TapKeySig => false,
             InputKey::TapScriptSig => true,
@@ -466,7 +466,7 @@ impl KeyType for InputKey {
             | InputKey::OutputIndex
             | InputKey::Sequence
             | InputKey::RequiredTimeLock
-            | InputKey::RequiredHeighLock => PsbtVer::V2,
+            | InputKey::RequiredHeightLock => PsbtVer::V2,
 
             InputKey::TapKeySig
             | InputKey::TapScriptSig
@@ -500,7 +500,7 @@ impl KeyType for InputKey {
             | InputKey::OutputIndex
             | InputKey::Sequence
             | InputKey::RequiredTimeLock
-            | InputKey::RequiredHeighLock
+            | InputKey::RequiredHeightLock
             | InputKey::TapKeySig
             | InputKey::TapScriptSig
             | InputKey::TapLeafScript
@@ -531,7 +531,7 @@ impl KeyType for InputKey {
             | InputKey::Hash256 => false,
 
             InputKey::PreviousTxid | InputKey::OutputIndex => true,
-            InputKey::Sequence | InputKey::RequiredTimeLock | InputKey::RequiredHeighLock => false,
+            InputKey::Sequence | InputKey::RequiredTimeLock | InputKey::RequiredHeightLock => false,
 
             InputKey::TapKeySig
             | InputKey::TapScriptSig