Fix spelling mistakes detected by newer codespell (ethereum#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

@@ -5,3 +5,6 @@ readded
 crate
 developper
 ist
+iam
+espace
+acn

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

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.

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)

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.
 

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
 

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"]}