Merge branch 'master' into eip-868-discussion-link

EIPS/eip-1011.md

@@ -107,7 +107,7 @@ This `CALL` utilizes no gas and does not increment the nonce of `NULL_SENDER`
 
 #### Casper Votes
 
-A `vote` transaction is defined as a transaction with the follow parameters:
+A `vote` transaction is defined as a transaction with the following parameters:
 
 * `TO`: `CASPER_ADDR`
 * `DATA`: Begins with `VOTE_BYTES`

EIPS/eip-1014.md

@@ -10,14 +10,14 @@ created: 2018-04-20
 
 ### Specification
 
-Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `sha3(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
+Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
 
 ### Motivation
 
 Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.
 
 #### Option 2
 
-Use `sha3(0xff ++ msg.sender ++ salt ++ init_code)[12:]`
+Use `keccak256(0xff ++ msg.sender ++ salt ++ init_code)[12:]`
 
-Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional `sha3(rlp([sender, nonce]))` formula, as 0xff can only be a starting byte for RLP for data many petabytes long.
+Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional `keccak256(rlp([sender, nonce]))` formula, as 0xff can only be a starting byte for RLP for data many petabytes long.

EIPS/eip-1066.md

@@ -105,7 +105,7 @@ explanatory and layout reasons.
 
 Unspecified codes are _not_ free for arbitrary use, but rather open for further specification.
 
-#### Generic
+#### `0x0*` Generic
 
 General codes. These double as bare "reasons", since `0x01 == 1`.
 
@@ -128,7 +128,7 @@ General codes. These double as bare "reasons", since `0x01 == 1`.
 | `0x0E`          |                         |
 | `0x0F`          | Meta or Info Only       |
 
-#### Permission
+#### `0x1*` Permission
 
 Related to permisson, authorization, approval, and so on.
 
@@ -151,7 +151,7 @@ Related to permisson, authorization, approval, and so on.
 | `0x1E`          |                          |
 | `0x1F`          | Permission Meta or Info  |
 
-#### Find, Match, &c
+#### `0x2*` Find, Match, &c
 
 This range is broadly intended for finding and matching.
 Data lookups and order matching are two common use cases.
@@ -175,7 +175,7 @@ Data lookups and order matching are two common use cases.
 | `0x2E`          |                          |
 | `0x2F`          | Matching Meta or Info    |
 
-#### Negotiation, Terms, and Offers
+#### `0x3*` Negotiation, Terms, and Offers
 
 Negotiation, and very broadly the flow of such transactions.
 Note that "other party" may be more than one actor (not necessarily the sender).
@@ -199,7 +199,7 @@ Note that "other party" may be more than one actor (not necessarily the sender).
 | `0x3E`          |                             |
 | `0x3F`          | Negotiation Meta or Info    |
 
-#### Availability
+#### `0x4*` Availability
 
 Service or action availability.
 
@@ -222,27 +222,27 @@ Service or action availability.
 | `0x4E`          |                             |
 | `0x4F`          | Availability Meta or Info   |
 
-#### `0x5_` TBD
+#### `0x5*` TBD
 
 Currently unspecified
 
-#### `0x6_` TBD
+#### `0x6*` TBD
 
 Currently unspecified
 
-#### `0x7_` TBD
+#### `0x7*` TBD
 
 Currently unspecified
 
-#### `0x8_` TBD
+#### `0x8*` TBD
 
 Currently unspecified
 
-#### `0x9_` TBD
+#### `0x9*` TBD
 
 Currently unspecified
 
-#### Application-Specific Codes
+#### `0xA*` Application-Specific Codes
 
 Contracts may have special states that they need to signal.
 This proposal only outlines the broadest meanings, but implementers may have very
@@ -267,19 +267,19 @@ specific meanings for each, as long as they are coherent with the broader defini
 | `0xAE`          |                                 |
 | `0xAF`          | App-Specific Meta or Info       |
 
-#### `0xB_` TBD
+#### `0xB*` TBD
 
 Currently unspecified
 
-#### `0xC_` TBD
+#### `0xC*` TBD
 
 Currently unspecified
 
-#### `0xD_` TBD
+#### `0xD*` TBD
 
 Currently unspecified
 
-#### Cryptography and Authentication
+#### `0xE*` Cryptography and Authentication
 
 Actions around signatures, cryptography, signing, and application-level authentication.
 
@@ -307,7 +307,7 @@ or process used.
 
 #### `0xF0` Off-Chain
 
-For off-chain actions. Much like th `0x0_: Generic` range, `0xF_` is very general,
+For off-chain actions. Much like th `0x0_: Generic` range, `0xF*` is very general,
 and does little to modify the reason.
 
 Among other things, the meta code `0xFF` may be used to describe what the off-chain process is.
@@ -489,7 +489,7 @@ most forwards-compatible method of transmission is as the first value of a multi
 
 Familiarity is also a motivating factor. A consistent position and encoding together
 follow the principle of least surprise. It is both viewable as a "header" in the HTTP analogy,
-or like the "tag" in BEAM tagged tupples.
+or like the "tag" in BEAM tagged tuples.
 
 ### Human Readable
 
@@ -500,7 +500,13 @@ Cognitive load is lowered by organizing the table into categories and reasons.
 While this repository includes helper enums, we have found working directly in
 the hex values to be quite natural. ESC `0x10` is just as comfortable as HTTP 401, for example.
 
-### Extensiblilty
+#### Localizations
+
+One commonly requested application of this spec is human-readable translations
+of codes. This has been moved to its own proposal: [ERC-1444](https://github.com/ethereum/EIPs/pull/1444/),
+primarily due to a desire to keep both specs focused.
+
+### Extensibility
 
 The `0xA` category is reserved for application-specific statuses.
 In the case that 256 codes become insufficient, `bytes1` may be embedded in larger byte arrays.
@@ -526,7 +532,7 @@ but becomes very natural after a couple hours of use.
 
 #### Short Forms
 
-Generic is `0x0_`, general codes are consistent with their integer representations
+Generic is `0x0*`, general codes are consistent with their integer representations
 
 ```solidity
 hex"1" == hex"01" == 1 // with casting

EIPS/eip-1108.md

@@ -13,8 +13,12 @@ requires: 196, 197
 
 Recent changes to the underlying library used by the official Go reference
 implementation led to significant performance gains for the `ECADD`, `ECMUL`,
-and pairing check precompiled contracts on the `alt_bn128` elliptic curve, which
-should be reflected in reduced gas costs.
+and pairing check precompiled contracts on the `alt_bn128` elliptic curve.
+
+What is more, the performance boost for those operations can be also observed 
+for Parity client. 
+
+Faster operations on Ethereum clients should be reflected in reduced gas costs.
 
 ## Motivation
 
@@ -29,20 +33,30 @@ note](https://github.com/ethereum/go-ethereum/pull/16301#issuecomment-372687543)
 the computational cost of `ECADD`, `ECMUL`, and pairing checks (excepting the
 constant) has dropped roughly an order of magnitude across the board.
 
+Also, [optimisations in the bn library](https://github.com/paritytech/bn/pull/9) 
+used by the [Parity client](https://github.com/paritytech/parity-ethereum) led to a 
+significant performance boost we 
+[benchmarked](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef) 
+and compared against the [previous 
+results](https://github.com/ethereum/benchmarking/blob/master/constantinople/analysis2.md). 
+
 ## Specification
 
 Following is a table with the current gas cost and new gas cost:
 
 | Contract      | Address   | Current Gas Cost               | Updated Gas Cost    |
 | ------------- | --------- | -----------------------------  | ------------------- |
-| `ECADD`       | `0x06`    | 500<sup>[1]</sup>              | 50                  |
-| `ECMUL`       | `0x07`    | 40 000<sup>[1]</sup>           | 2 000               |
-| Pairing check | `0x08`    | 80 000k + 100 000<sup>[2]</sup>| 5 500k + 80 000     |
+| `ECADD`       | `0x06`    | 500<sup>[1]</sup>              | 150                 |
+| `ECMUL`       | `0x07`    | 40 000<sup>[1]</sup>           | 6 000               |
+| Pairing check | `0x08`    | 80 000 * k + 100 000<sup>[2]</sup>| 28 300 * k + 35 450    |
 
 The gas costs for `ECADD` and `ECMUL` are updates to the costs listed in
 EIP-196, while the gas costs for the pairing check are updates to the cost
-listed in EIP-197.
+listed in EIP-197. Updated gas costs have been adjusted to the less performant 
+client which is Parity, according to benchmarks<sup>[3]</sup>.
 
 [1]- Per [EIP-196](https://github.com/ethereum/EIPs/blob/984cf5de90bbf5fbe7e49be227b0c2f9567e661e/EIPS/eip-196.md#gas-costs).
 
 [2]- Per [EIP-197](https://github.com/ethereum/EIPs/blob/df132cd37efb3986f9cd3ef4922b15a767d2c54a/EIPS/eip-197.md#specification).
+
+[3]- [Parity benchmarks.](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef)