Merge branch 'ethereum:master' into master

ERCS/erc-1046.md

@@ -97,7 +97,7 @@ The resolved JSON of the `tokenURI` described in the ERC-20 Interface Extension
  */
 interface ERC20TokenMetadata {
     /**
-     * Interoperabiliy, to differentiate between different types of tokens and their corresponding URIs.
+     * Interoperability, to differentiate between different types of tokens and their corresponding URIs.
      **/
     interop: InteroperabilityMetadata;
 
@@ -157,7 +157,7 @@ Contracts that implement ERC-721 and use its token metadata URI SHOULD to use th
 ```typescript
 interface ERC721TokenMetadataInterop extends ERC721TokenMetadata {
     /**
-     * Interoperabiliy, to avoid confusion between different token URIs
+     * Interoperability, to avoid confusion between different token URIs
      **/
     interop: InteroperabilityMetadata;
 }
@@ -189,7 +189,7 @@ Contracts that implement ERC-1155 and use its token metadata URI are RECOMMENDED
 ```typescript
 interface ERC1155TokenMetadataInterop extends ERC1155TokenMetadata {
     /**
-     * Interoperabiliy, to avoid confusion between different token URIs
+     * Interoperability, to avoid confusion between different token URIs
      **/
     interop: InteroperabilityMetadata;
 }

ERCS/erc-1077.md

@@ -174,7 +174,7 @@ Contracts are not obligated to support ether or any other token they don’t wan
 This scheme opens up a great deal of possibilities on interaction as well as different experiments on business models:
 
 * Apps can create individual identities contract for their users which holds the actual funds and then create a different private key for each device they log into. Other apps can use the same identity and just ask to add permissioned public keys to manage the device, so that if one individual key is lost, no ether is lost.
-* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
+* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
 * A game company creates games with a traditional monthly subscription, either by credit card or platform-specific microtransactions. Private keys never leave the device and keep no ether and only the public accounts are sent to the company. The game then signs transactions on the device with gas price 0, sends them to the game company which checks who is an active subscriber and batches all transactions and pays the ether themselves. If the company goes bankrupt, the gamers themselves can set up similar subscription systems or just increase the gas price. End result is a **ethereum based game in which gamers can play by spending apple, google or xbox credits**.
 * A standard token is created that doesn’t require its users to have ether, and instead allows tokens to be transferred by paying in tokens. A wallet is created that signs messages and send them via whisper to the network, where other nodes can compete to download the available transactions, check the current gas price, and select those who are paying enough tokens to cover the cost. **The result is a token that the end users never need to keep any ether and can pay fees in the token itself.**
 * A DAO is created with a list of accounts of their employees. Employees never need to own ether, instead they sign messages, send them to whisper to a decentralized list of relayers which then deploy the transactions. The DAO contract then checks if the transaction is valid and sends ether to the deployers. Employees have an incentive not to use too many of the companies resources because they’re identifiable.  The result is that the users of the DAO don't need to keep ether, and **the contract ends up paying for it's own gas usage**.

ERCS/erc-1123.md

@@ -1593,7 +1593,7 @@ A URI in the format `blockchain://<chain_id>/block/<block_hash>`
 -   `block_hash` is the unprefixed hexadecimal representation of the
     hash of a block on the chain.
 
-A chain is considered to match a chain definition if the the genesis
+A chain is considered to match a chain definition if the genesis
 block hash matches the `chain_id` and the block defined by `block_hash`
 can be found on that chain. It is possible for multiple chains to match
 a single URI, in which case all chains are considered valid matches

ERCS/erc-1132.md

@@ -111,7 +111,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```solidity
 /**
   * @dev Returns unlockable tokens for a specified address for a specified reason
-  * @param _of The address to query the the unlockable token count of
+  * @param _of The address to query the unlockable token count of
   * @param _reason The reason to query the unlockable tokens for
   */
   function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
@@ -120,7 +120,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```solidity
 /**
   * @dev Gets the unlockable tokens of a specified address
-  * @param _of The address to query the the unlockable token count of
+  * @param _of The address to query the unlockable token count of
   */
   function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
 ```

ERCS/erc-1363.md

@@ -99,6 +99,7 @@ interface ERC1363 /* is ERC20, ERC165 */ {
    * and then call `onApprovalReceived` on spender.
    * @param spender address The address which will spend the funds
    * @param value uint256 The amount of tokens to be spent
+   * @return true unless throwing
    */
   function approveAndCall(address spender, uint256 value) external returns (bool);
 
@@ -108,6 +109,7 @@ interface ERC1363 /* is ERC20, ERC165 */ {
    * @param spender address The address which will spend the funds
    * @param value uint256 The amount of tokens to be spent
    * @param data bytes Additional data with no specified format, sent in call to `spender`
+   * @return true unless throwing
    */
   function approveAndCall(address spender, uint256 value, bytes memory data) external returns (bool);
 }

ERCS/erc-1444.md

@@ -135,7 +135,7 @@ Text with 2 or more arguments SHOULD use the POSIX parameter field extension.
 
 `bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (card(A) > 1.1579 × 10<sup>77</sup>), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width.
 
-Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](./eip-1066.md)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the the larger one.
+Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](./eip-1066.md)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the larger one.
 
 ### Local vs Globals and Singletons
 

ERCS/erc-2019.md

@@ -218,7 +218,7 @@ Emitted when a given player, operator, company or a given persona, has been appr
 | Parameter | Description |
 | ---------|-------------|
 | walletToFund | The wallet that the player is allowed to start funding requests |
-| orderer | The address that allows the the player to start requests. |
+| orderer | The address that allows the player to start requests. |
 
 #### FundOperatorRevoked
 
@@ -227,7 +227,7 @@ Emitted when a given player has been revoked initiate funding requests.
 | Parameter | Description |
 | ---------|-------------|
 | walletToFund | The wallet that the player is allowed to start funding requests |
-| orderer | The address that allows the the player to start requests. |
+| orderer | The address that allows the player to start requests. |
 
 ## Rationale
 This standards provides a functionality to allow token holders to start funding requests in a decentralized way.

ERCS/erc-2021.md

@@ -249,7 +249,7 @@ Emitted when a given player, operator, company or a given persona, has been appr
 | Parameter | Description |
 | ---------|-------------|
 | walletToBePaidOut | The wallet that the player is allowed to start payout requests |
-| orderer |The address that allows the the player to start requests. |
+| orderer |The address that allows the player to start requests. |
 
 #### PayoutOperatorRevoked
 
@@ -258,7 +258,7 @@ Emitted when a given player has been revoked initiate payout requests.
 | Parameter | Description |
 | ---------|-------------|
 | walletToBePaidOut | The wallet that the player is allowed to start payout requests |
-| orderer |The address that allows the the player to start requests. |
+| orderer |The address that allows the player to start requests. |
 
 ## Rationale
 This standards provides a functionality to allow token holders to start payout requests in a decentralized way.

ERCS/erc-2135.md

@@ -157,7 +157,7 @@ Compliant contracts should pay attention to the balance change when a token is c
 When the contract is being paused, or the user is being restricted from transferring a token,
 the consumeability should be consistent with the transferral restriction.
 
-Compliant contracts should also carefully define access control, particularlly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
+Compliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
 
 Security audits and tests should be used to verify that the access control to the `consume`
 function behaves as expected.

ERCS/erc-2304.md

@@ -12,7 +12,7 @@ requires: 137
 
 ## Abstract
 
-This EIP introduces new overloads for the the `addr` field for ENS resolvers, which permit resolution of addresses for other blockchains via ENS.
+This EIP introduces new overloads for the `addr` field for ENS resolvers, which permit resolution of addresses for other blockchains via ENS.
 
 ## Motivation
 

ERCS/erc-2309.md

@@ -88,7 +88,7 @@ Standardizing the `ConsecutiveTransfer` event gives decentralized platforms a st
 
 Take this example. I sell magical fruit and have a farm with 10,000 magical fruit trees each with different fruit and 1,000 new trees every few years. I want to turn each tree into a non-fungible token that people can own. Each person that owns one of my non-fungible tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.
 
-With this extension I would be able to to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
+With this extension I would be able to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
 
 **Rationale to have a single event that covers minting, burning, and transferring**
 

ERCS/erc-2333.md

@@ -1,7 +1,7 @@
 ---
 eip: 2333
 title: BLS12-381 Key Generation
-author: Carl Beekhuizen <carl@ethereum.org>
+author: Carl Beekhuizen (@CarlBeek) <carl@ethereum.org>
 discussions-to: https://github.com/ethereum/EIPs/issues/2337
 status: Stagnant
 type: Standards Track

ERCS/erc-2334.md

@@ -1,7 +1,7 @@
 ---
 eip: 2334
 title: BLS12-381 Deterministic Account Hierarchy
-author: Carl Beekhuizen <carl@ethereum.org>
+author: Carl Beekhuizen (@CarlBeek) <carl@ethereum.org>
 discussions-to: https://github.com/ethereum/EIPs/issues/2338
 status: Stagnant
 type: Standards Track

ERCS/erc-2335.md

@@ -1,7 +1,7 @@
 ---
 eip: 2335
 title: BLS12-381 Keystore
-author: Carl Beekhuizen <carl@ethereum.org>
+author: Carl Beekhuizen (@CarlBeek) <carl@ethereum.org>
 discussions-to: https://github.com/ethereum/EIPs/issues/2339
 status: Stagnant
 type: Standards Track
@@ -106,7 +106,7 @@ This field is an optional field to help explain the purpose and identify a parti
 
 ## PubKey
 
-The `pubkey` is the public key associated with the the private key secured within the keystore. It is stored here to improve user experience and security which is achieved by not requiring users to enter their password just to obtain their public keys. This field is required if the secret being stored within the keystore is a private key. The encoding of the `pubkey` is specified in the in the appropriate signature standard (eg. [BLS12-381 signature standard](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-00)), but can be seen as a byte-string in the abstract and should be directly compatible with the appropriate signature library.
+The `pubkey` is the public key associated with the private key secured within the keystore. It is stored here to improve user experience and security which is achieved by not requiring users to enter their password just to obtain their public keys. This field is required if the secret being stored within the keystore is a private key. The encoding of the `pubkey` is specified in the in the appropriate signature standard (eg. [BLS12-381 signature standard](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-00)), but can be seen as a byte-string in the abstract and should be directly compatible with the appropriate signature library.
 
 ## Path
 

ERCS/erc-2615.md

@@ -229,7 +229,7 @@ Powered by Truffle and Openzeppelin test helper.
 
 ## Implementation
 
-[Github Reposotory](https://github.com/kohshiba/ERC-X).
+[Github Repository](https://github.com/kohshiba/ERC-X).
 
 ## Security Considerations
 

ERCS/erc-2678.md

@@ -872,7 +872,7 @@ A URI in the format `blockchain://<chain_id>/block/<block_hash>`
 -   `block_hash` is the unprefixed hexadecimal representation of the
     hash of a block on the chain.
 
-A chain is considered to match a chain definition if the the genesis
+A chain is considered to match a chain definition if the genesis
 block hash matches the `chain_id` and the block defined by `block_hash`
 can be found on that chain. It is possible for multiple chains to match
 a single URI, in which case all chains are considered valid matches

ERCS/erc-2917.md

@@ -50,11 +50,11 @@ interface IERC2917 is IERC20 {
     event InterestRatePerBlockChanged (uint oldValue, uint newValue);
 
     /// @dev This emit when a users' productivity has changed
-    /// It emits with the user's address and the the value after the change.
+    /// It emits with the user's address and the value after the change.
     event ProductivityIncreased (address indexed user, uint value);
 
     /// @dev This emit when a users' productivity has changed
-    /// It emits with the user's address and the the value after the change.
+    /// It emits with the user's address and the value after the change.
     event ProductivityDecreased (address indexed user, uint value);
 
     
@@ -106,12 +106,12 @@ This emit when interests amount per block is changed by the owner of the contrac
 
 ### ProductivityIncreased
 
-It emits with the user's address and the the value after the change.
+It emits with the user's address and the value after the change.
 
 
 ### ProductivityDecreased
 
-It emits with the user's address and the the value after the change. 
+It emits with the user's address and the value after the change. 
 
 ### interestsPerBlock
 

ERCS/erc-3448.md

@@ -182,7 +182,7 @@ function getMetadataWithoutCall () public pure returns (
 ```solidity
 /// @notice Returns the metadata of this (MetaProxy) contract.
 /// Only relevant with contracts created via the MetaProxy standard.
-/// @dev This function is aimed to to be invoked via a call.
+/// @dev This function is aimed to be invoked via a call.
 function getMetadataViaCall () public pure returns (
   address a,
   uint256 b,

ERCS/erc-3668.md

@@ -80,7 +80,7 @@ error OffchainLookup(address sender, string[] urls, bytes callData, bytes4 callb
 
 `urls` specifies a list of URL templates to services (known as gateways) that implement the CCIP read protocol and can formulate an answer to the query. `urls` can be the empty list `[]`, in which case the client MUST specify the URL template. The order in which URLs are tried is up to the client, but contracts SHOULD return them in order of priority, with the most important entry first.
 
-Each URL may include two substitution parameters, `{sender}` and `{data}`. Before a call is made to the URL, `sender` is replaced with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and `data` is replaced by the the 0x-prefixed hexadecimal formatted `callData` parameter.
+Each URL may include two substitution parameters, `{sender}` and `{data}`. Before a call is made to the URL, `sender` is replaced with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and `data` is replaced by the 0x-prefixed hexadecimal formatted `callData` parameter.
 
 `callData` specifies the data to call the gateway with. This value is opaque to the client. Typically this will be ABI-encoded, but this is an implementation detail that contracts and gateways can standardise on as desired.
 
@@ -176,7 +176,7 @@ contract NestedLookup {
 ### Gateway Interface
 The URLs returned by a contract may be of any schema, but this specification only defines how clients should handle HTTPS URLs.
 
-Given a URL template returned in an `OffchainLookup`, the URL to query is composed by replacing  `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the the 0x-prefixed hexadecimal formatted `callData` parameter.
+Given a URL template returned in an `OffchainLookup`, the URL to query is composed by replacing  `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the 0x-prefixed hexadecimal formatted `callData` parameter.
 
 For example, if a contract returns the following data in an `OffchainLookup`:
 
@@ -293,7 +293,7 @@ A client that supports CCIP read MUST make contract calls using the following pr
  3. If the function returns an error other than `OffchainLookup`, return it to the caller in the usual fashion.
  4. Otherwise, decode the `sender`, `urls`, `callData`, `callbackFunction` and `extraData` arguments from the `OffchainLookup` error.
  5. If the `sender` field does not match the address of the contract that was called, return an error to the caller and stop.
- 6. Construct a request URL by replacing `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the the 0x-prefixed hexadecimal formatted `callData` parameter. The client may choose which URLs to try in which order, but SHOULD prioritise URLs earlier in the list over those later in the list.
+ 6. Construct a request URL by replacing `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the 0x-prefixed hexadecimal formatted `callData` parameter. The client may choose which URLs to try in which order, but SHOULD prioritise URLs earlier in the list over those later in the list.
  7. Make an HTTP GET request to the request URL.
  8. If the response code from step (5) is in the range 400-499, return an error to the caller and stop.
  9. If the response code from step (5) is in the range 500-599, go back to step (5) and pick a different URL, or stop if there are no further URLs to try.