Merge pull request #15 from ethereum/master

update

EIPS/eip-1.md

@@ -93,7 +93,7 @@ Image files should be included in a subdirectory of the `assets` folder for that
 
 ## EIP Header Preamble
 
-Each EIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (`---`). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
+Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
 
 ` eip:` <EIP number> (this is determined by the EIP editor)
 

EIPS/eip-100.md

@@ -1,7 +1,7 @@
 ---
 eip: 100
 title: Change difficulty adjustment to target mean block time including uncles
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-1077.md

@@ -1,7 +1,7 @@
 ---
 eip: 1077
 title: Executable Signed Messages refunded by the contract
-author: Alex Van de Sande <[email protected]>, Ricardo Guilherme Schmidt
+author: Alex Van de Sande <[email protected]>, Ricardo Guilherme Schmidt (@3esmit)
 discussions-to: https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351
 status: Draft
 type: Standards Track

EIPS/eip-1155.md

@@ -17,7 +17,7 @@ A standard interface for contracts that manage multiple token types. A single de
 
 ## Abstract
 
-This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each Token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.
+This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.
 
 The `_id` argument contained in each function's argument set indicates a specific token or token type in a transaction.
 
@@ -115,16 +115,16 @@ interface ERC1155 /* is ERC165 */ {
     /**
         @notice Get the balance of an account's Tokens.
         @param _owner  The address of the token holder
-        @param _id     ID of the Token
-        @return        The _owner's balance of the Token type requested
+        @param _id     ID of the token
+        @return        The _owner's balance of the token type requested
      */
     function balanceOf(address _owner, uint256 _id) external view returns (uint256);
 
     /**
         @notice Get the balance of multiple account/token pairs
         @param _owners The addresses of the token holders
         @param _ids    ID of the Tokens
-        @return        The _owner's balance of the Token types requested (i.e. balance for each (owner, id) pair)
+        @return        The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair)
      */
     function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
 
@@ -165,7 +165,7 @@ interface ERC1155TokenReceiver {
         Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller.
         @param _operator  The address which initiated the transfer (i.e. msg.sender)
         @param _from      The address which previously owned the token
-        @param _id        The id of the token being transferred
+        @param _id        The ID of the token being transferred
         @param _value     The amount of tokens being transferred
         @param _data      Additional data with no specified format
         @return           `bytes4(keccak256("accept_erc1155_tokens()"))`
@@ -253,6 +253,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
 * MUST revert on any other error.
 * MUST emit the `TransferSingle` event to reflect the balance change (see "TransferSingle and TransferBatch event rules" section).
 * After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section).
+    - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `onERC1155Received` hook function via its `_data` argument.
 
 **_safeBatchTransferFrom rules:_**
 * Caller must be approved to manage all the tokens being transferred out of the `_from` account (see "Approval" section).
@@ -262,7 +263,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
 * MUST revert on any other error.
 * MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section).
 * The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc).
-* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section).
+* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "onERC1155Received and onERC1155BatchReceived rules" section).
+    - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `ERC1155TokenReceiver` hook function(s) via their `_data` argument.
 
 **_TransferSingle and TransferBatch event rules:_**
 * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair.
@@ -295,7 +297,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
     - `_from` MUST be 0x0 for a mint.
 * The `_id` argument MUST be the token type being transferred.
 * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.
-* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer.
+* The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered.
     - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer.
 * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_erc1155_tokens()"))`
     - If the return value is `bytes4(keccak256("accept_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success.
@@ -312,8 +314,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
     - `_from` MUST be 0x0 for a mint.    
 * The `_ids` argument MUST be the list of tokens being transferred.
 * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by.
-* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer.
-    - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer.
+* The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered.
+    - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeBatchTransferFrom` call for this transfer.
 * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_batch_erc1155_tokens()"))`
     - If the return value is `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success.
 * The recipient contract MAY reject an increase of its balance by calling revert.
@@ -538,7 +540,7 @@ fr.json:
 ### Approval
 
 The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](https://eips.ethereum.org/EIPS/eip-1761) is suggested.
-The counterpart `isAprrovedForAll` provides introspection into status set by `setApprovalForAll`.
+The counterpart `isApprovedForAll` provides introspection into status set by `setApprovalForAll`.
 
 An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call `setApprovalForAll` to approve themselves as an operator before they can operate on them.  
 
@@ -570,7 +572,7 @@ As the Ethereum ecosystem continues to grow, many dapps are relying on tradition
 
 The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts.
 
-Restricting approval to a certain set of Token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155.
+Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155.
 
 ## Usage
 
@@ -588,7 +590,7 @@ The `balanceOfBatch` function allows clients to retrieve balances of multiple ow
 
 ### Enumerating from events
 
-In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the Token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.
+In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.
 
 ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBatch` events in any instance where tokens are created, minted, or destroyed.
 

EIPS/eip-145.md

@@ -1,7 +1,7 @@
 ---
 eip: 145
 title: Bitwise shifting instructions in EVM
-author: Alex Beregszaszi (@axic), Paweł Bylica
+author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-1485.md

@@ -1,7 +1,7 @@
 ---
 eip: 1485
 title: TEthashV1
-author: trustfarm (KT Ahn - 안씨아저씨) <[email protected]>, <[email protected]>,
+author: trustfarm (KT Ahn - 안씨아저씨) <[email protected]>, trustfarm <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/anti-eth-asic-mining-eip-1488-pr/1807
 status: Draft
 type: Standards Track

EIPS/eip-150.md

@@ -1,7 +1,7 @@
 ---
 eip: 150
 title: Gas cost changes for IO-heavy operations
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-155.md

@@ -1,7 +1,7 @@
 ---
 eip: 155
 title: Simple replay attack protection
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-160.md

@@ -1,7 +1,7 @@
 ---
 eip: 160
 title: EXP cost increase
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-162.md

@@ -243,3 +243,6 @@ This document borrows heavily from several sources:
 - 2016-10-26 Added link Alex's design in abstract
 - 2016-11-01 change 'Planned deactivation' to h3'
 - 2017-03-13 Update timelines for bidding and reveal periods
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-165.md

@@ -151,7 +151,7 @@ contract ERC165Query {
                                     30000,         // 30k gas
                                     _contract,     // To addr
                                     x,             // Inputs are stored at location x
-                                    0x20,          // Inputs are 32 bytes long
+                                    0x24,          // Inputs are 36 bytes long
                                     x,             // Store output over input (saves space)
                                     0x20)          // Outputs are 32 bytes long
 
@@ -225,6 +225,11 @@ contract Homer is ERC165, Simpson {
 
 With three or more supported interfaces (including ERC165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case).
 
+## Version history
+* PR 1640, finalized 2019-01-23 -- This corrects the noThrowCall test case to use 36 bytes rather than the previous 32 bytes. The previous code was an error that still silently worked in Solidity 0.4.x but which was broken by new behavior introduced in Solidity 0.5.0. This change was discussed at [#1640](https://github.com/ethereum/EIPs/pull/1640).
+
+* EIP 165, finalized 2018-04-20 -- Original published version.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1679.md

@@ -49,6 +49,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
 - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes
 - [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available.
 - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction
+- [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles
 
 ## Timeline
 

EIPS/eip-170.md

@@ -1,7 +1,7 @@
 ---
 eip: 170
 title: Contract code size limit
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-181.md

@@ -204,3 +204,6 @@ This registrar, written in Solidity, implements the specifications outlined abov
             }
         }
     }
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).