From eb9ba13fa269e4f81f93c110ce98dc4a6450a387 Mon Sep 17 00:00:00 2001 From: Dr Maxim Orlovsky Date: Sun, 18 Aug 2024 10:30:21 +0200 Subject: [PATCH] chore: fix typos --- README.md | 69 ++++++++++++++++++++++-------------------- SECURITY.md | 19 ++++++------ _typos.toml | 7 +++++ derive/src/taptree.rs | 18 +++++------ invoice/src/address.rs | 2 +- psbt/src/coders.rs | 2 +- psbt/src/keys.rs | 16 +++++----- psbt/src/maps.rs | 6 ++-- 8 files changed, 75 insertions(+), 64 deletions(-) create mode 100644 _typos.toml diff --git a/README.md b/README.md index 15a6117..0f83de1 100644 --- a/README.md +++ b/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,14 +62,15 @@ 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 @@ -76,36 +78,36 @@ The library doesn't rely on `rust-bitcoin` crate. The reasons for that are: 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 diff --git a/SECURITY.md b/SECURITY.md index 22101c1..78489f2 100644 --- a/SECURITY.md +++ b/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 diff --git a/_typos.toml b/_typos.toml new file mode 100644 index 0000000..181ff5d --- /dev/null +++ b/_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" diff --git a/derive/src/taptree.rs b/derive/src/taptree.rs index af2681a..22ff819 100644 --- a/derive/src/taptree.rs +++ b/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, + leaves: Vec, buoy: MerkleBuoy, 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) -> Result { + pub fn from_leaves(leaves: impl IntoIterator) -> Result { let mut builder = TapTreeBuilder::new(); - for leaf in leafs { + for leaf in leaves { builder.push_leaf(leaf)?; } builder.finish().map_err(InvalidTree::from) diff --git a/invoice/src/address.rs b/invoice/src/address.rs index 3687244..693b105 100644 --- a/invoice/src/address.rs +++ b/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, diff --git a/psbt/src/coders.rs b/psbt/src/coders.rs index 8fdd48e..18e7071 100644 --- a/psbt/src/coders.rs +++ b/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) } } diff --git a/psbt/src/keys.rs b/psbt/src/keys.rs index d6ce1f3..28c0cc2 100644 --- a/psbt/src/keys.rs +++ b/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 diff --git a/psbt/src/maps.rs b/psbt/src/maps.rs index 4d62bef..2dfdee9 100644 --- a/psbt/src/maps.rs +++ b/psbt/src/maps.rs @@ -434,7 +434,7 @@ impl KeyMap for Input { InputKey::OutputIndex => once!(self.previous_outpoint.vout), InputKey::Sequence => option!(self.sequence_number), InputKey::RequiredTimeLock => option!(self.required_time_lock), - InputKey::RequiredHeighLock => option!(self.required_height_lock), + InputKey::RequiredHeightLock => option!(self.required_height_lock), InputKey::TapKeySig => option!(self.tap_key_sig), InputKey::TapScriptSig => iter!(self.tap_script_sig), InputKey::TapLeafScript => iter!(self.tap_leaf_script), @@ -483,7 +483,7 @@ impl KeyMap for Input { InputKey::RequiredTimeLock => { self.required_time_lock = Some(LockTimestamp::deserialize(value_data)?) } - InputKey::RequiredHeighLock => { + InputKey::RequiredHeightLock => { self.required_height_lock = Some(LockHeight::deserialize(value_data)?) } @@ -533,7 +533,7 @@ impl KeyMap for Input { | InputKey::OutputIndex | InputKey::Sequence | InputKey::RequiredTimeLock - | InputKey::RequiredHeighLock => unreachable!(), + | InputKey::RequiredHeightLock => unreachable!(), InputKey::PartialSig => { let pk = LegacyPk::deserialize(key_data)?;