From 219a7a5441008e00274b1da0d27b90f87c281363 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Wed, 3 Jun 2020 00:22:07 +0100 Subject: [PATCH] Fix spelling mistakes detected by newer codespell (#2683) * Add iam to codespell-whitelist (used as a variable name) * Allow french spelling in the whitelist * Allow ACN (australian company number) in the whitelist * Fix misspellings --- .codespell-whitelist | 3 +++ EIPS/eip-107.md | 2 +- EIPS/eip-1581.md | 2 +- EIPS/eip-1613.md | 2 +- EIPS/eip-1930.md | 2 +- EIPS/eip-2333.md | 2 +- EIPS/eip-758.md | 2 +- 7 files changed, 9 insertions(+), 6 deletions(-) diff --git a/.codespell-whitelist b/.codespell-whitelist index 21c9c7e4ce907a..ce96dc07405aa7 100644 --- a/.codespell-whitelist +++ b/.codespell-whitelist @@ -5,3 +5,6 @@ readded crate developper ist +iam +espace +acn diff --git a/EIPS/eip-107.md b/EIPS/eip-107.md index 67caa48d96d459..d6a79c2b53cf3e 100644 --- a/EIPS/eip-107.md +++ b/EIPS/eip-107.md @@ -95,7 +95,7 @@ Rationale The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code. The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guarantess by browsers' cross domain policies. -The use of iframe/ window was required to have both security and user friendliness. The invisble iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653). +The use of iframe/ window was required to have both security and user friendliness. The invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653). Implementations diff --git a/EIPS/eip-1581.md b/EIPS/eip-1581.md index e49d8e76f382dd..1c5808fc5d8200 100644 --- a/EIPS/eip-1581.md +++ b/EIPS/eip-1581.md @@ -10,7 +10,7 @@ created: 2018-11-13 --- ## Simple Summary -This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet keypairs. +This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet key pairs. ## Abstract BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets. diff --git a/EIPS/eip-1613.md b/EIPS/eip-1613.md index a5a45fe576a63d..41360e7b437dbd 100644 --- a/EIPS/eip-1613.md +++ b/EIPS/eip-1613.md @@ -86,7 +86,7 @@ Glossary of terms used in the processes below: * `RelayHub` - the RelayHub singleton contract, used by everyone. * `Recipient` - a contract implementing `RelayRecipient`, accepting relayed transactions from the RelayHub contract and paying for the incoming transactions. -* `Sender` - an external address with a valid keypair but no ETH to pay for gas. +* `Sender` - an external address with a valid key pair but no ETH to pay for gas. * `Relay` - a node holding ETH in an external address, listed in RelayHub and relaying transactions from Senders to RelayHub for a fee. ![Sequence Diagram](https://bit.ly/2WZqM23) diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index 3e611128572a08..9c20100888fe61 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -88,7 +88,7 @@ This is an issue for contracts that require external call to only fails if they But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the ```supporstInterface``` method is bounded to use 30,000 gas so that it is theorically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call. -Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. +Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interpreting wrongly that the callee is not implementing the interface in question. While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that [bug report](https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9) or after the call (see the native meta transaction implementation [here](https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176), it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow [EIP-150](https://eips.ethereum.org/EIPS/eip-150) behavior and the current gas pricing so closely. diff --git a/EIPS/eip-2333.md b/EIPS/eip-2333.md index 261a0653a85989..d74fc3c6bcb6e3 100644 --- a/EIPS/eip-2333.md +++ b/EIPS/eip-2333.md @@ -68,7 +68,7 @@ Every key generated via the key derivation process derives a child key via a set ##### Outputs -* `lamport_SK`, an array of 255 32-octet stings +* `lamport_SK`, an array of 255 32-octet strings ##### Definitions diff --git a/EIPS/eip-758.md b/EIPS/eip-758.md index 5cc85bb6f2a86c..eb71ae5febc725 100644 --- a/EIPS/eip-758.md +++ b/EIPS/eip-758.md @@ -69,7 +69,7 @@ Suppose the caller then submits a transaction via `eth_sendTransaction` or `eth_ } ``` -The caller receives notifications about their transactions in two cases: first when a transaction is sealed, and again (with an extra `"removed": true` field) if a transaction is affected by a chain reorganization. Notifications are sent to the client for all transactions submitted from the client that are sealed _after_ subscribing. If `from`, `to`, or `hasReturnData` is specified, then only those matching the filter criteria will generate notificaitons. As with other subscriptions, the caller can send an `eth_unsubscribe` RPC request to stop receiving push notifications: +The caller receives notifications about their transactions in two cases: first when a transaction is sealed, and again (with an extra `"removed": true` field) if a transaction is affected by a chain reorganization. Notifications are sent to the client for all transactions submitted from the client that are sealed _after_ subscribing. If `from`, `to`, or `hasReturnData` is specified, then only those matching the filter criteria will generate notifications. As with other subscriptions, the caller can send an `eth_unsubscribe` RPC request to stop receiving push notifications: ```json {"jsonrpc": "2.0", "id": 2, "method": "eth_unsubscribe", "params": ["0x00000000000000000000000000000b0b"]}