Merge branch 'master' into master

.gitattributes

@@ -0,0 +1,3 @@
+# GitHub highlighting for Solidity files
+# See https://github.com/github/linguist/pull/3973#issuecomment-357507741
+*.sol linguist-language=Solidity

.travis-ci.sh

@@ -22,6 +22,6 @@ elif [[ $TASK = 'eip-validator' ]]; then
     exit 1
   fi
 
-  FILES=$(ls EIPS/*.md)
+  FILES="$(ls EIPS/*.md | egrep "eip-[0-9]+.md")"
   bundle exec eip_validator $FILES
 fi

EIPS/eip-1066.md

@@ -93,15 +93,15 @@ function safeIncrement(uint8 interval) public returns (byte status, uint8 newCou
 }
 ```
 
-In the rare case that there a multiple codes required to express an idea,
-they should be organized in asending order.
+In the rare case that there are multiple codes required to express an idea,
+they should be organized in ascending order.
 
 ### Code Table
 
 Codes break nicely into a 16x16 matrix, represented as a 2-digit hex number.
 The high nibble represents the code's kind or "category", and the low nibble contains
 the state or "reason". We present them below as separate tables per range for
-explanitory and layout reasons.
+explanatory and layout reasons.
 
 Unspecified codes are _not_ free for arbitrary use, but rather open for further specification.
 
@@ -178,7 +178,7 @@ Data lookups and order matching are two common use cases.
 #### Negotiation, Terms, and Offers
 
 Negotiation, and very broadly the flow of such transactions.
-Note that "other party" may be more than one actor (not nessesarily the sender).
+Note that "other party" may be more than one actor (not necessarily the sender).
 
 |  Code           | Description                 |
 |-----------------|:----------------------------|

EIPS/eip-1077.md

@@ -47,22 +47,25 @@ The signed messages require the following fields:
 
 #### Signing the message
 
-All accounts that will be requesting the transaction must sign a messageHash that is calculated by the following formula:
+In order to be compliant, the transaction **MUST** request to sign a messageHash that is a concatenation of multiple fields, plus one final field `extraData` that can be left blank but is added for forward compatibility.
+
+The fields **MUST** be concatenated in this order:
 
 ```
 keccak256(
     byte(0x19),
     byte(0),
     from,
-    callPrefix,
     to,
     value,
     dataHash,
     nonce,
     gasPrice,
     gasLimit,
     gasToken,
-    operationType
+    callPrefix,
+    operationType,
+    extraHash
 );
 ```
 
@@ -72,7 +75,16 @@ The `from` field will always be the contract executing the code (`address(this)`
 
 `operationType` type will define what sort of operation will be executed (in assembly): 0 for a standard `call`, 1 for a `DelegateCall` and 0 for a `create` opcode. These can be extended in the future.
 
-All signed messageHashes should then be ordered by account and sent to the receiveing contract which then will execute the following actions:
+#### Backwards and forwards capability:
+
+Not all executable signed messages contracts will have the same requirements, therefore some fields are optional. Fields `byte(0x19)`, `byte(0)`, `from`, `to`, `value`, `dataHash` are **obligatory** while `nonce`, `gasPrice`, `gasLimit`, `gasToken`, `callPrefix`, `operationType` are optional, but must be hashed in this order. 
+
+Regardless of which fields you use, in your contract you **must** accept an extraHash that is always hashed at the end. This is done to increase future compatibility of the standard: solidity's keccak treats `keccak(a, b, c, d, e, f)` as identical to `keccak(a, b, concat(c, d, e, f)`. therefore by adding an extra field in the end that can be ignored by your contract, you allow it to be compatible with the same standard as other message standards that use it to sign it.
+
+
+#### Multiple signatures
+
+If multiple signatures are required, then all signed messageHashes should then be *ordered by account* and sent to the receiveing contract which then will execute the following actions:
 
 #### keep track of nonces:
 
@@ -115,7 +127,8 @@ executeSigned(
 	uint gasPrice,
 	uint gasLimit,
 	address gasToken,
-	operationType
+	operationType,
+	extraHash,
 	bytes messageSignatures)
 `
 
@@ -133,7 +146,8 @@ gasEstimate(
 	uint gasPrice,
 	uint gasLimit,
 	address gasToken,
-	operationType
+	operationType,
+	extraHash
 	bytes messageSignatures)
 	returns (
 	bool canExecute,

EIPS/eip-1102.md

@@ -0,0 +1,119 @@
+---
+eip: 1102
+title: Opt-in web3 access
+author: Paul Bouchon <[email protected]>
+discussions-to: https://ethereum-magicians.org/t/opt-in-web3-access/414
+status: Draft
+type: Standards Track
+category: Interface
+created: 2018-05-04
+---
+
+## Simple summary
+
+This proposal describes a new way for DOM environments to expose the web3 API that requires user approval.
+
+## Abstract
+
+MetaMask and most other tools that provide access to web3-enabled environments do so automatically and without user consent. This exposes users of such environments to fingerprinting attacks since untrusted websites can check for a `web3` object and reliably identify web3-enabled clients.
+
+This proposal outlines a new protocol in which dapps request access to the web3 API instead of relying on its preexistence in a given DOM environment.
+
+## Specification
+
+### Typical dapp initialization
+
+```
+START dapp
+IF web3 is defined
+    CONTINUE dapp
+IF web3 is undefined
+    STOP dapp
+```
+
+### Proposed dapp initialization
+
+```
+START dapp
+IF web3 is defined
+    CONTINUE dapp
+IF web3 is undefined
+    REQUEST[1] web3 API
+    IF user approves
+        INJECT[2] web3 API
+        NOTIFY[3] dapp
+        CONTINUE dapp
+    IF user rejects
+    IF non-web3 environment
+        NOOP[4]
+```
+
+#### `[1] REQUEST`
+
+Dapps MUST request the web3 API by sending a message using [`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) API. This message MUST be sent with a payload object containing a `type` property with a value of “WEB3_API_REQUEST” and an optional `id` property corresponding to an identifier of a specific wallet provider, such as "METAMASK".
+
+#### `[2] INJECT`
+
+Dapp browsers should inject the web3 API using an implementation-specific strategy that can expose the web3 API to the user’s browser context, such as HTML script tag injection.
+
+#### `[3] NOTIFY`
+
+Dapps browsers MUST notify dapps of successful web3 exposure by sending a message using [`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) API. This message MUST be sent with a payload object containing a `type` property with a value of “WEB3_API_SUCCESS" and an optional `id` property corresponding to an identifier of a specific wallet provider, such as "METAMASK".
+
+#### `[4] NOOP`
+
+If a user rejects web3 access on an untrusted site, the site itself MUST NOT be notified in any way; notification of a rejection would allow third-party tools to still identify that a client is web3-enabled despite not being granted web3 access.
+
+### Example implementation: `postMessage`
+
+The following example demonstrates one possible implementation of this strategy in a browser-based DOM environment. Note that web3 environments on other platforms would most likely use platform-specific native messaging protocols, not `postMessage`.
+
+```js
+if (typeof web3 !== 'undefined') {
+    // web3 API defined, start dapp
+} else {
+    window.addEventListener('message', function (event) {
+        if (!event.data || !event.data.type) { return; }
+        if (event.data.type === 'WEB3_API_SUCCESS') {
+            // web3 API defined, start dapp
+        }
+    });
+    // request web3 API
+    window.postMessage({ type: 'WEB3_API_REQUEST' });
+}
+```
+
+## Rationale
+
+An [open issue](https://github.com/MetaMask/metamask-extension/issues/714) against the [MetaMask](https://github.com/MetaMask/metamask-extension) extension has received community upvotes and Richard Burton of the [Balance](https://github.com/balance-io) team published a well-received [blog post](https://medium.com/@ricburton/metamask-walletconnect-js-b47857efb4f7) discussing these potential changes.
+
+### Constraints
+
+* Web3 MUST NOT be exposed to websites by default.
+* Dapps MUST request web3 if it does not exist.
+* Users MUST be able to approve or reject web3 access.
+* Web3 MUST be exposed to websites after user consent.
+* Environments MAY continue auto-exposing web3 if users can disable this behavior.
+
+### Immediate value-add
+
+* Users can reject web3 access on untrusted sites to prevent web3 fingerprinting.
+
+### Long-term value-add
+
+* Dapps could request specific account information based on user consent.
+* Dapps could request specific user information based on user consent (uPort, DIDs).
+* Dapps could request a specific network based on user consent.
+* Dapps could request multiple instances of the above based on user consent.
+
+## Backwards compatibility
+
+This proposal impacts dapp authors and requires that they request access to the web3 API before using it. This proposal also impacts developers of web3-enabled environments or dapp browsers as these tools should no longer auto-expose the web3 API; instead, they should only do so if a website requests the API and if the user consents to its access. Environments may continue to auto-expose the web3 API as long as users have the ability to disable this behavior.
+
+## Implementation
+
+The MetaMask team is currently working an [MVP implementation](https://github.com/MetaMask/metamask-extension/issues/3930) of the strategy described above and expects to begin limited user testing soon.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1108.md

@@ -0,0 +1,48 @@
+---
+eip: 1108
+title: Reduce alt_bn128 precompile gas costs
+author: Antonio Salazar Cardozo (@shadowfiend)
+status: Draft
+type: Standards Track
+category: Core
+created: 2018-05-21
+requires: 196, 197
+---
+
+## Short Description
+
+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.
+
+## Motivation
+
+Recently, the underlying library used by the [official Go reference
+implementation](https://github.com/ethereum/go-ethereum) to implement the
+`ECADD` (at address `0x06`), `ECMUL` (at address `0x07`), and pairing check (at
+address `0x08`) precompiled contracts was shifted to [Cloudflare's bn256
+library](https://github.com/cloudflare/bn256). Based on the [initial PR that
+introduced this change](https://github.com/ethereum/go-ethereum/pull/16203),
+and corroborated in [a later
+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.
+
+## 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     |
+
+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.
+
+[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).