Update with master branch.

EIPS/eip-1.md

@@ -44,7 +44,7 @@ Each EIP must have a champion - someone who writes the EIP using the style and f
 
 Vetting an idea publicly before going as far as writing an EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP.
 
-Once the champion has asked the Ethereum community whether an idea has any chance of acceptance a draft EIP should be presented as a [pull request]. 
+Once the champion has asked the Ethereum community whether an idea has any chance of acceptance a draft EIP should be presented as a [pull request].
 
 If the EIP collaborators approve, the EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP. Reasons for denying EIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Ethereum philosophy.
 
@@ -64,7 +64,7 @@ EIPs can also be superseded by a different EIP, rendering the original obsolete.
 
 The possible paths of the status of EIPs are as follows:
 
-![EIP Process](eip-1/process.png)
+![EIP Process](../assets/eip-1/process.png)
 
 Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP).
 
@@ -114,7 +114,8 @@ Each EIP should have the following parts:
 EIP Formats and Templates
 -------------------------
 
-EIPs should be written in [markdown] format. Image files should be included in a subdirectory for that EIP.
+EIPs should be written in [markdown] format.
+Image files should be included in a subdirectory of the `assets` folder for that EIP as follow: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`.
 
 EIP Header Preamble
 -------------------

EIPS/eip-107.md

@@ -29,19 +29,19 @@ Account unlocked :
 -----------------
 When the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make:
 
-![](eip-107/authorization.png)
+![](../assets/eip-107/authorization.png)
 
 Account locked and no "personal" api exposed via rpc:
 -----------------
 When the account is locked, and the node does not provide access to account unlocking via its rpc interface, the following popup will be presented. This is not ideal since this requires the user to know how to unlock an account:
 
-![](eip-107/authorization-locked.png)
+![](../assets/eip-107/authorization-locked.png)
 
 Account locked but node exposing the "personal" api via rpc :
 -----------------
 A better option is to ask the user for their password, but this is only possible if the node allows access to the "personal" api via rpc. In such case, the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account:
 
-![](eip-107/authorization-password.png)
+![](../assets/eip-107/authorization-password.png)
 
 
 Specification

EIPS/eip-191.md

@@ -0,0 +1,63 @@
+---
+eip: 191
+title: Signed Data Standard
+author: Martin Holst Swende (@holiman), Nick Johnson <[email protected]>
+status: Draft
+type: Standards Track
+category: ERC
+created: 2016-01-20
+---
+
+# Abstract
+
+This ERC proposes a specification about how to handle signed data in Etherum contracts.
+
+# Motivation
+
+Several multisignature wallet implementations have been created which accepts `presigned` transactions. A `presigned` transaction is a chunk of binary `signed_data`, along with signature (`r`, `s` and `v`). The interpretation of the `signed_data` has not been specified, leading to several problems:
+
+* Standard Ethereum transactions can be submitted as `signed_data`. An Ethereum transaction can be unpacked, into the following components: `RLP<nonce, gasPrice, startGas, to, value, data>` (hereby called `RLPdata`), `r`, `s` and `v`. If there are no syntactical constraints on `signed_data`, this means that `RLPdata` can be used as a syntactically valid `presigned` transaction.
+* Multisignature wallets have also had the problem that a `presigned` transaction has not been tied to a particular `validator`, i.e a specific wallet. Example:
+    1. Users `A`, `B` and `C` have the `2/3`-wallet `X`
+    2. Users `A`, `B` and `D` have the `2/3`-wallet `Y`
+    3. User `A` and `B` submites `presigned` transaction to `X`.
+    4. Attacker can now reuse their presigned transactions to `X`, and submit to `Y`.
+
+## Specification
+
+We propose the following format for `signed_data`
+
+```
+0x19 <1 byte version> <version specific data> <data to sign>.
+```
+Version `0` has `<20 byte address>` for the version specific data, and the `address` is the intended validator. In the case of a Multisig wallet, that is the wallet's own address  .
+
+The initial `0x19` byte is intended to ensure that the `signed_data` is not valid [RLP](https://github.com/ethereum/wiki/wiki/RLP)
+
+> For a single byte whose value is in the [0x00, 0x7f] range, that byte is its own RLP encoding.
+
+That means that any `signed_data` cannot be one RLP-structure, but a 1-byte `RLP` payload followed by something else. Thus, any ERC-191 `signed_data` can never be an Ethereum transaction.
+
+Additionally, `0x19` has been chosen because since ethereum/go-ethereum#2940 , the following is prepended before hashing in personal_sign:
+
+```
+"\x19Ethereum Signed Message:\n" + len(message).
+```
+
+Using `0x19` thus makes it possible to extend the scheme by defining a version `0x45` (`E`) to handle these kinds of signatures.
+
+### Example
+
+    function submitTransactionPreSigned(address destination, uint value, bytes data, uint nonce, uint8 v, bytes32 r, bytes32 s)
+        public
+        returns (bytes32 transactionHash)
+    {
+        // Arguments when calculating hash to validate
+        // 1: byte(0x19) - the initial 0x19 byte
+        // 2: byte(0) - the version byte
+        // 3: this - the validator address
+        // 4-7 : Application specific data
+        transactionHash = keccak256(byte(0x19),byte(0),this,destination, value, data, nonce);
+        sender = ecrecover(transactionHash, v, r, s);
+        // ...
+    }

EIPS/eip-3.md

@@ -2,7 +2,7 @@
 eip: 3
 title: Addition of CALLDEPTH opcode
 author: Martin Holst Swende <[email protected]>
-status: Draft
+status: Deferred
 type: Standards Track
 category: Core
 created: 2015-11-19

EIPS/eip-609.md

@@ -2,8 +2,7 @@
 eip: 609
 title: "Hardfork Meta: Byzantium"
 author: Alex Beregszaszi
-type: Standards Track
-category: Core
+type: Meta
 status: Final
 created: 2017-04-23
 requires: 100, 140, 196, 197, 198, 211, 214, 649, 658

EIPS/eip-615.md

@@ -211,9 +211,8 @@ Validating that jumps are to valid addresses takes two sequential passes over th
 
     bool validate_jumps(PC)
     {
-        current_sub = PC
-
         // build sets of BEGINSUBs and JUMPDESTs
+        current_sub = 0
         for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC))
         {
             if instruction is invalid
@@ -230,6 +229,7 @@ Validating that jumps are to valid addresses takes two sequential passes over th
         }
 
         // check that targets are in subroutine
+        current_sub = 0
         for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC))
         {
             if instruction is BEGINDATA

EIPS/eip-616.md

@@ -1,7 +1,7 @@
 ---
 eip: 616
 title: SIMD Operations for the EVM
-author: Greg Colvin, [email protected]
+author: Greg Colvin <[email protected]>
 type: Standards Track
 category: Core
 status: Draft

EIPS/eip-627.md

@@ -0,0 +1,183 @@
+---
+eip: 627
+title: Whisper Specification
+author: Vlad Gluhovsky <[email protected]>
+type: Informational
+status: Draft
+created: 2017-05-05
+---
+
+## Abstract
+
+This draft EIP describes the format of Whisper messages within the ÐΞVp2p Wire Protocol.
+This EIP should substitute the [existing specification](https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol).
+More detailed documentation on Whisper could be found [here](https://github.com/ethereum/go-ethereum/wiki/Whisper).
+
+## Motivation
+
+It is necessary to specify the standard for Whisper messages in order to ensure forward compatibility of different Whisper clients.
+
+## Specification
+
+All Whisper messages sent as ÐΞVp2p Wire Protocol packets should be RLP-encoded arrays of data containing two objects: integer packet code followed by another object (whose type depends on the packet code). 
+
+If Whisper node does not support a particular packet code, it should just ignore the packet without generating any error.
+
+### Packet Codes
+
+The message codes reserved for Whisper protocol: 0 - 127.
+Messages with unknown codes must be ignored, for forward compatibility of future versions.
+
+The Whisper sub-protocol should support the following packet codes:
+
+| EIP   | Name                       | Int Value |
+|-------|----------------------------|-----------|
+|       | Status                     |     0     |
+|       | Messages                   |     1     |
+|       | PoW Requirement            |     2     |
+|       | Bloom Filter               |     3     |
+|-------|----------------------------|-----------|
+
+
+The following message codes are optional, but they are reserved for specific purpose.
+
+| EIP   | Name                       | Int Value |
+|-------|----------------------------|-----------|
+|       | P2P Request                |    126    |
+|       | P2P Message                |    127    |
+|-------|----------------------------|-----------|
+
+### Packet Format and Usage
+
+**Status** [`0`]
+
+This packet contains two objects: integer message code (0x00) followed by a list of values: integer version, float PoW requirement, and bloom filter, in this order. The bloom filter paramenter is optional; if it is missing or nil, the node is considered to be full node (i.e. accepts all messages). The format of PoW and bloom filter please see below (message codes 2 and 3).
+
+Status message should be sent after the initial handshake and prior to any other messages.
+
+**Messages** [`1`, `whisper_envelopes`]
+
+This packet contains two objects: integer message code (0x01) followed by a list (possibly empty) of Whisper Envelopes.
+
+This packet is used for sending the standard Whisper envelopes.
+
+**PoW Requirement** [`2`, `PoW`]
+
+This packet contains two objects: integer message code (0x02) followed by a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed.
+
+This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Receipient of this message should no longer deliver the sender messages with PoW lower than specified in this message.
+
+PoW is defined as average number of iterations, required to find the current BestBit (the number of leading zero bits in the hash), divided by message size and TTL:
+
+	PoW = (2**BestBit) / (size * TTL)
+
+PoW calculation:
+
+	fn short_rlp(envelope) = rlp of envelope, excluding env_nonce field.
+	fn pow_hash(envelope, env_nonce) = sha3(short_rlp(envelope) ++ env_nonce)
+	fn pow(pow_hash, size, ttl) = 2**leading_zeros(pow_hash) / (size * ttl)
+
+where size is the size of the full RLP-encoded envelope.
+
+**Bloom Filter** [`3`, `bytes`]
+
+This packet contains two objects: integer message code (0x03) followed by a byte array of arbitrary size.
+
+This packet is used by Whisper nodes for sharing their interest in messages with specific topics.
+
+The Bloom filter is used to identify a number of topics to a peer without compromising (too much) privacy over precisely what topics are of interest. Precise control over the information content (and thus efficiency of the filter) may be maintained through the addition of bits.
+
+Blooms are formed by the bitwise OR operation on a number of bloomed topics. The bloom function takes the topic and projects them onto a 512-bit slice. At most, three bits are marked for each bloomed topic.
+
+The projection function is defined as a mapping from a 4-byte slice S to a 512-bit slice D; for ease of explanation, S will dereference to bytes, whereas D will dereference to bits.
+
+	LET D[*] = 0
+	FOREACH i IN { 0, 1, 2 } DO
+	LET n = S[i]
+	IF S[3] & (2 ** i) THEN n += 256
+	D[n] = 1
+	END FOR
+
+
+OPTIONAL
+
+**P2P Request** [`126`, `whisper_envelope`]
+
+This packet contains two objects: integer message code (0x7E) followed by a single Whisper Envelope.
+
+This packet is used for sending Dapp-level peer-to-peer requests, e.g. Whisper Mail Client requesting old messages from the Whisper Mail Server.
+
+**P2P Message** [`127`, `whisper_envelope`]
+
+This packet contains two objects: integer message code (0x7F) followed by a single Whisper Envelope.
+
+This packet is used for sending the peer-to-peer messages, which are not supposed to be forwarded any further. E.g. it might be used by the Whisper Mail Server for delivery of old (expired) messages, which is otherwise not allowed.
+
+
+### Whisper Envelope
+
+Envelopes are RLP-encoded structures of the following format:
+
+	[ Expiry, TTL, Topic, Data, Nonce ]
+
+`Expiry`: 4 bytes (UNIX time in seconds).
+
+`TTL`: 4 bytes (time-to-live in seconds).
+
+`Topic`: 4 bytes of arbitrary data.
+
+`Data`: byte array of arbitrary size (contains encrypted message).
+
+`Nonce`: 8 bytes of arbitrary data (used for PoW calculation).
+
+### Contents of Data Field of the Message (Optional)
+
+This section outlines the optional description of Data Field to set up an example. Later it may be moved to a separate EIP.
+
+It is only relevant if you want to decrypt the incoming message, but if you only want to send a message, any other format would be perfectly valid and must be forwarded to the peers.
+
+Data field contains encrypted message of the Envelope. In case of symmetric encryption, it also contains appended Salt (a.k.a. AES Nonce, 12 bytes). Plaintext (unencrypted) payload consists of the following concatenated fields: flags, auxiliary field, payload, padding and signature (in this sequence).
+
+	flags: 1 byte; first two bits contain the size of auxiliary field, third bit indicates whether the signature is present.
+
+	auxiliary field: up to 4 bytes; contains the size of payload.
+
+	payload: byte array of arbitrary size (may be zero).
+
+	padding: byte array of arbitrary size (may be zero).
+
+	signature: 65 bytes, if present.
+
+	salt: 12 bytes, if present (in case of symmetric encryption).
+
+Those unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` are both big-endian encoded, fixed-width 256-bit unsigned. `V` is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.
+
+The padding field was introduced in order to align the message size, since message size alone might reveal important metainformation. Padding can be arbitrary size. However, it is recommended that the size of Data Field (excuding the Salt) before encryption (i.e. plain text) should be factor of 256 bytes.
+
+### Payload Encryption
+
+Asymmetric encryption uses the standard Elliptic Curve Integrated Encryption Scheme with SECP-256k1 public key.
+
+Symmetric encryption uses AES GCM algorithm with random 96-bit nonce.
+
+## Rationale
+
+Packet codes 0x00 and 0x01 are already used in all Whisper versions.
+
+Packet code 0x02 will be necessary for the future developement of Whisper. It will provide possiblitity to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement.
+
+Packet code 0x03 will be necessary for scalability of the network. In case of too much traffic, the nodes will be able to request and receive only the messages they are interested in.
+
+Packet codes 0x7E and 0x7F may be used to implement Whisper Mail Server and Client. Without P2P messages it would be impossible to deliver the old messages, since they will be recognized as expired, and the peer will be disconnected for violating the Whisper protocol. They might be useful for other purposes when it is not possible to spend time on PoW, e.g. if a stock exchange will want to provide live feed about the latest trades.
+
+## Backwards Compatibility
+
+This EIP is compatible with Whisper version 6. Any client which does not implement certain packet codes should gracefully ignore the packets with those codes. This will ensure the forward compatibility. 
+
+## Implementation
+
+The golang implementation of Whisper (v.6) already uses packet codes 0x00 - 0x03. Parity's implementation of v.6 will also use codes 0x00 - 0x03. Codes 0x7E and 0x7F are reserved, but still unused and left for custom implementation of Whisper Mail Server.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-681.md

@@ -37,7 +37,7 @@ Payment request URLs contain "ethereum" in their schema (protocol) part and are
     number                  = [ "-" / "+" ] *DIGIT [ "." 1*DIGIT ] [ ( "e" / "E" ) [ 1*DIGIT ] [ "+" UNIT ]
 
 
-Where `TYPE` is a standard ABI type name, as defined in [Ethereum Contract ABI specification](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI). `STRING` is a URL-encoded unicode string of arbitrary length, where delimiters and the
+Where `TYPE` is a standard ABI type name, as defined in [Ethereum Contract ABI specification](https://solidity.readthedocs.io/en/develop/abi-spec.html). `STRING` is a URL-encoded unicode string of arbitrary length, where delimiters and the
 percentage symbol (`%`) are mandatorily hex-encoded with a `%` prefix.
 
 `UNIT` is a URL-encoded unicode string. If `UNIT` is ETH, it always means a multiplier of 10<sup>18</sup>. If it is something