Codespell doc fixes

Author: iartemov-ledger

doc/bitcoin.md

@@ -65,7 +65,7 @@ Once the user approves, the `REGISTER_WALLET` returns to the client a 32-byte HM
 | 0xE000 | `SW_INTERRUPTED_EXECUTION`   | The command is interrupted, and requires the client's response |
 | 0x9000 | `SW_OK`                      | Success |
 
-<!-- TODO: add an introduction section explaining the comand reference notations (e.g. the Bitcoin style varint) -->
+<!-- TODO: add an introduction section explaining the command reference notations (e.g. the Bitcoin style varint) -->
 
 ## Commands
 
@@ -106,7 +106,7 @@ The paths defined in [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-00
 
 If the `display` parameter is `0` and the path is not standard, an error is returned.
 
-If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user. 
+If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user.
 
 ### REGISTER_WALLET
 
@@ -214,9 +214,9 @@ Given a PSBTv2 and a registered wallet (or a standard one), sign all the inputs
 | `<var>` | `global_map_size`      | The number of key/value pairs of the global map of the psbt |
 | `32`    | `global_map_keys_root` | The Merkle root of the keys of the global map |
 | `32`    | `global_map_vals_root` | The Merkle root of the values of the global map |
-| `<var>` | `n_inputs`             | The number of inputs of the psbt | 
+| `<var>` | `n_inputs`             | The number of inputs of the psbt |
 | `32`    | `inputs_maps_root`     | The Merkle root of the vector of Merkleized map commitments for the input maps |
-| `<var>` | `n_outputs`            | The number of outputs of the psbt | 
+| `<var>` | `n_outputs`            | The number of outputs of the psbt |
 | `32`    | `outputs_maps_root`    | The Merkle root of the vector of Merkleized map commitments for the output maps |
 | `32`    | `wallet_id`            | The id of the wallet |
 | `32`    | `wallet_hmac`          | The hmac of a registered wallet, or exactly 32 0 bytes |
@@ -382,7 +382,7 @@ The response must contain:
 - `1` byte: a 1-byte unsigned integer `b`, the length of the prefix of the pre-image that is part of the response;
 - `b` bytes: corresponding to the first `b` bytes of the preimage.
 
-If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one ore more `GET_MORE_ELEMENTS` requests.
+If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one or more `GET_MORE_ELEMENTS` requests.
 
 ### GET_MERKLE_LEAF_PROOF
 

doc/merkle.md

@@ -9,15 +9,15 @@ Operations on Merkle trees are composed to create commitments to more complex da
 ## Merkle trees
 ### Definition
 
-A Merkle tree allows to create a commitment to an arbitrarily large list of values; short membership proofs can be provided that can be verified solely withthe knowledge of a single hash (the Merkle tree root)
+A Merkle tree allows to create a commitment to an arbitrarily large list of values; short membership proofs can be provided that can be verified solely with the knowledge of a single hash (the Merkle tree root)
 
 Our implementation of Merkle trees loosely follow the structure defined in [RFC 6962](https://www.rfc-editor.org/rfc/pdfrfc/rfc6962.txt.pdf), using SHA-256 as the hash function. We refer to the linked document for a more detailed description. Only one difference (the hash of the empty list) is defined below.
 
 We call a *byte string* an arbitrary array of bytes, where each byte is a value between `0` and `255`. A *hash function* takes as input an arbitrary length byte string, and produces a fixed-length output. Outputs of SHA-256 are 32 bytes long.
 
 Following the notation of RFC 6962, we are given an ordered list of inputs `D[n] = {d(0), d(1), ..., d(n-1)}`, where each element `d(i)` is a byte string. We denote with `||` the concatenation operator, and with `D[a:b]` the list `{d(a), d(a+1), ..., d(b - 1)}`.
 
-We define the Merkle Tree Hash (MTH) (also called the *Merkle root*) as follows. 
+We define the Merkle Tree Hash (MTH) (also called the *Merkle root*) as follows.
 
 The hash of the empty list is `MTH({}) = 0`, a string of 32 bytes identically equal to `0`. *This definition differs from RFC 6962*.
 

doc/v0/bitcoin.md

@@ -62,7 +62,7 @@ Once the user approves, the `REGISTER_WALLET` returns to the client a 32-byte HM
 | 0xE000 | `SW_INTERRUPTED_EXECUTION`   | The command is interrupted, and requires the client's response |
 | 0x9000 | `SW_OK`                      | Success |
 
-<!-- TODO: add an introduction section explaining the comand reference notations (e.g. the Bitcoin style varint) -->
+<!-- TODO: add an introduction section explaining the command reference notations (e.g. the Bitcoin style varint) -->
 
 ## Commands
 
@@ -103,7 +103,7 @@ The paths defined in [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-00
 
 If the `display` parameter is `0` and the path is not standard, an error is returned.
 
-If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user. 
+If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user.
 
 ### REGISTER_WALLET
 
@@ -209,9 +209,9 @@ Given a PSBTv2 and a registered wallet (or a standard one), sign all the inputs
 | `<var>` | `global_map_size`      | The number of key/value pairs of the global map of the psbt |
 | `32`    | `global_map_keys_root` | The Merkle root of the keys of the global map |
 | `32`    | `global_map_vals_root` | The Merkle root of the values of the global map |
-| `<var>` | `n_inputs`             | The number of inputs of the psbt | 
+| `<var>` | `n_inputs`             | The number of inputs of the psbt |
 | `32`    | `inputs_maps_root`     | The Merkle root of the vector of Merkleized map commitments for the input maps |
-| `<var>` | `n_outputs`            | The number of outputs of the psbt | 
+| `<var>` | `n_outputs`            | The number of outputs of the psbt |
 | `32`    | `outputs_maps_root`    | The Merkle root of the vector of Merkleized map commitments for the output maps |
 | `32`    | `wallet_id`            | The id of the wallet |
 | `32`    | `wallet_hmac`          | The hmac of a registered wallet, or exactly 32 0 bytes |
@@ -352,7 +352,7 @@ The response must contain:
 - `1` byte: a 1-byte unsigned integer `b`, the length of the prefix of the pre-image that is part of the response;
 - `b` bytes: corresponding to the first `b` bytes of the preimage.
 
-If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one ore more `GET_MORE_ELEMENTS` requests.
+If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one or more `GET_MORE_ELEMENTS` requests.
 
 ### GET_MERKLE_LEAF_PROOF
 
@@ -414,4 +414,4 @@ All the current commands use a commit-and-reveal approach: the APDU that starts
 - If a Merkle proof is asked via `GET_MERKLE_LEAF_PROOF`, the proof is verified.
 - If the index of a leaf is asked `GET_MERKLE_LEAF_INDEX`, the proof for that element is requested via `GET_MERKLE_LEAF_PROOF` and the proof verified, *even if the leaf value is known*.
 
-Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).
+Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).

doc/v0/wallet.md

@@ -27,9 +27,9 @@ Key placeholder `KP` expressions consist of
 - a single character `@`
 - followed by a non-negative decimal number, with no leading zeros (except for `@0`).
 
-The placeholder `@i` for some number *i* represents the *i*-th key in the vector of key orgin informations (which must be of size at least *i* + 1, or the wallet is invalid. 
+The placeholder `@i` for some number *i* represents the *i*-th key in the vector of key origin information (which must be of size at least *i* + 1, or the wallet is invalid.
 
-Each element of the *key origin informations* list is a `KEY` expression.
+Each element of the *key origin information* list is a `KEY` expression.
 `KEY` expressions:
 
 -   Key origin information, consisting of:
@@ -61,7 +61,7 @@ The app supports a number of features related to wallet policies. In order to se
 
 - register a wallet, validating all the information (policy and keys involved) with the user on the trusted screen;
 - show the addresses for a registered wallet on the trusted screen;
-- sign spends from the wallet. 
+- sign spends from the wallet.
 
 Since the application is stateless, wallet registration is not persisted on device. In order to make it possible to use a registered wallet in future requests, the device returns a hmac-sha256 (32 bytes long) for the wallet upon a successful registration. The client side is responsible for persisting the wallet policy *and* the returned hmac-sha256, and to provide this information in future requests.
 
@@ -122,4 +122,4 @@ A few policies that correspond to standardized single-key wallets can be used wi
 - ``sh(wpkh(@0))`` - nested segwit addresses as per [BIP-49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki)
 - ``tr(@0)`` - single Key P2TR as per [BIP-86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki)
 
-Note that the wallet policy is considered standard (and therefore usable for signing without prior registration) only if the signing paths (defined in the key origin information) adheres to the corresponding BIP.
+Note that the wallet policy is considered standard (and therefore usable for signing without prior registration) only if the signing paths (defined in the key origin information) adheres to the corresponding BIP.

doc/wallet.md

@@ -5,7 +5,7 @@ a wallet descriptor template and the vector of key placeholder expressions.
 
 A _wallet descriptor template_ follows language very similar to output descriptor, with a few differences; the biggest one is that each `KEY` expression with a key placeholder `KP` expression, that refers to one of the keys in the _keys information vector_, plus the additional derivation steps to use for that key. Contextually, the keys information vector contains all the relevant _xpubs_, and possibly their key origin information.
 
-Each entry in the key information vector contains an _xpub_ (other types of keys supported in output script descriptors are not allowed), possible preceeded by the key origin information. The key origin information is compulsory for internal keys.
+Each entry in the key information vector contains an _xpub_ (other types of keys supported in output script descriptors are not allowed), possible preceded by the key origin information. The key origin information is compulsory for internal keys.
 
 This section formally defines wallet policies, and how they relate to
 output script descriptors.
@@ -127,7 +127,7 @@ The app supports a number of features related to wallet policies. In order to se
 
 - register a wallet, validating all the information (policy and keys involved) with the user on the trusted screen;
 - show the addresses for a registered wallet on the trusted screen;
-- sign spends from the wallet. 
+- sign spends from the wallet.
 
 Since the application is stateless, wallet registration is not persisted on device. In order to make it possible to use a registered wallet in future requests, the device returns a hmac-sha256 (32 bytes long) for the wallet upon a successful registration. The client side is responsible for persisting the wallet policy *and* the returned hmac-sha256, and to provide this information in future requests.