Merge README.md

EIPS/eip-1.md

@@ -174,19 +174,13 @@ The current EIP editors are
 
 ` * Casey Detrio (@cdetrio)`
 
-` * Fabian Vogelsteller (@frozeman)`
-
-` * Gavin Wood (@gavofyork)`
-
 ` * Hudson Jameson (@Souptacular)`
 
-` * Jeffrey Wilcke (@obscuren)`
-
 ` * Martin Becze (@wanderer)`
 
 ` * Nick Johnson (@arachnid)`
 
-` * Roman Mandeleil (@romanman)`
+` * Yoichi Hirai (@pirapira)`
 
 ` * Vitalik Buterin (@vbuterin)`
 

EIPS/eip-100.md

@@ -0,0 +1,39 @@
+```
+EIP: 100
+Title: Change difficulty adjustment to target mean block time including uncles
+Author: Vitalik Buterin
+Type: Standard Track
+Category: Core
+Status: Accepted
+Created: 2016-04-28
+```
+
+### Specification
+
+Currently, the formula to compute the difficulty of a block includes the following logic:
+
+``` python
+adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99)
+child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF)))
+...
+```
+
+If `block.number >= METROPOLIS_FORK_BLKNUM`, we change the first line to the following:
+
+``` python
+adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99)
+```
+### Rationale
+
+This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles:
+``` python
+adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)
+```
+can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with `k` uncles is equivalent to a sequence of `k+1` blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash).
+
+Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%).
+
+### References
+
+1. EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100
+2. https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/

EIPS/eip-145.md

@@ -0,0 +1,94 @@
+## Preamble
+
+    EIP: 145
+    Title: Bitwise shifting instructions in EVM
+    Author: Alex Beregszaszi, Paweł Bylica
+    Type: Standard Track
+    Category: Core
+    Status: Final
+    Created: 2017-02-13
+
+
+## Simple Summary
+
+To provide native bitwise shifting with cost on par with other arithmetic operations.
+
+## Abstract
+
+Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.
+
+## Motivation
+
+EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetics cost each 35 gas, while the proposed instructions take 3 gas.
+
+## Specification
+
+The following instructions are introduced:
+
+### `0x1b`: `SHL` (shift left)
+
+The `SHL` instruction (shift left) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the left by `arg1` number of bits. The result is equal to
+
+```
+(arg2 * 2^arg1) mod 2^256
+```
+
+Notes:
+- The value (`arg2`) is interpreted as an unsigned number.
+- The shift amount (`arg1`) is interpreted as an unsigned number.
+- If the shift amount (`arg1`) is greater or equal 256 the result is 0.
+- This is equivalent to `PUSH1 2 EXP MUL`.
+
+### `0x1c`: `SHR` (logical shift right)
+
+The `SHR` instruction (logical shift right) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the right by `arg1` number of bits with zero fill. The result is equal to
+
+```
+floor(arg2 / 2^arg1)
+```
+
+Notes:
+- The value (`arg2`) is interpreted as an unsigned number.
+- The shift amount (`arg1`) is interpreted as an unsigned number.
+- If the shift amount (`arg1`) is greater or equal 256 the result is 0.
+- This is equivalent to `PUSH1 2 EXP DIV`.
+
+### `0x1d`: `SAR` (arithmetic shift right)
+
+The `SAR` instruction (arithmetic shift right) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the right by `arg1` number of bits with sign extension. The result is equal to
+
+```
+floor(arg2 / 2^arg1)
+```
+
+Notes:
+- The value (`arg2`) is interpreted as a signed number.
+- The shift amount (`arg1`) is interpreted as an unsigned number.
+- If the shift amount (`arg1`) is greater or equal 256 the result is 0 if `arg2` is non-negative or -1 if `arg2` is negative.
+- This is **not** equivalent to `PUSH1 2 EXP SDIV`, since it rounds differently. See `SDIV(-1, 2) == 0`, while `SAR(-1, 1) == -1`.
+
+The cost of the shift instructions is set at `verylow` tier (3 gas).
+
+## Rationale
+
+Instruction operands were chosen to fit the more natural use case of shifting a value already on the stack. This means the operand order is swapped compared to most arithmetic insturctions.
+
+## Backwards Compatibility
+
+The newly introduced instructions have no effect on bytecode created in the past.
+
+## Test Cases
+
+TBA
+
+## Implementation
+
+Client support:
+- cpp-ethereum: https://github.com/ethereum/cpp-ethereum/pull/4054
+
+Compiler support:
+- Solidity/LLL: https://github.com/ethereum/solidity/pull/2541
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-190.md

@@ -1,8 +1,8 @@
 ```
-EIP: Draft
+EIP: 190
 Title: Ethereum Smart Contract Packaging Standard
 Authors: Piper Merriam, Tim Coulter, Denis Erfurt (mhhf), RJ Catalano (VoR0220), Iuri Matias (iurimatias)
-Status: Draft
+Status: Final
 Type: Standards Track - ERC
 Created: 2017-01-10
 ```

EIPS/eip-20-token-standard.md

@@ -0,0 +1,184 @@
+## Preamble
+
+    EIP: 20
+    Title: ERC-20 Token Standard
+    Author: Fabian Vogelsteller <fabian@ethereum.org>, Vitalik Buterin <vitalik.buterin@ethereum.org>
+    Type: Standard
+    Category: ERC
+    Status: Accepted
+    Created: 2015-11-19
+
+
+## Simple Summary
+
+A standard interface for tokens.
+
+
+## Abstract
+
+The following standard allows for the implementation of a standard API for tokens within smart contracts.
+This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.
+
+
+## Motivation
+
+A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges.
+
+
+## Specification
+
+## Token
+### Methods
+
+**NOTE**: Callers MUST handle `false` from `returns (bool success)`.  Callers MUST NOT assume that `false` is never returned!
+
+
+#### name
+
+Returns the name of the token - e.g. `"MyToken"`.
+
+OPTIONAL - This method can be used to improve usability,
+but interfaces and other contracts MUST NOT expect these values to be present.
+
+
+``` js
+function name() constant returns (string name)
+```
+
+
+#### symbol
+
+Returns the symbol of the token. E.g. "HIX".
+
+OPTIONAL - This method can be used to improve usability,
+but interfaces and other contracts MUST NOT expect these values to be present.
+
+``` js
+function symbol() constant returns (string symbol)
+```
+
+
+
+#### decimals
+
+Returns the number of decimals the token uses - e.g. `8`, means to divide the token amount by `100000000` to get its user representation.
+
+OPTIONAL - This method can be used to improve usability,
+but interfaces and other contracts MUST NOT expect these values to be present.
+
+``` js
+function decimals() constant returns (uint8 decimals)
+```
+
+
+#### totalSupply
+
+Returns the total token supply.
+
+``` js
+function totalSupply() constant returns (uint256 totalSupply)
+```
+
+
+
+#### balanceOf
+
+Returns the account balance of another account with address `_owner`.
+
+``` js
+function balanceOf(address _owner) constant returns (uint256 balance)
+```
+
+
+
+#### transfer
+
+Transfers `_value` amount of tokens to address `_to`, and MUST fire the `Transfer` event.
+The function SHOULD `throw` if the `_from` account balance does not have enough tokens to spend.
+
+A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created.
+
+*Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event.
+
+``` js
+function transfer(address _to, uint256 _value) returns (bool success)
+```
+
+
+
+#### transferFrom
+
+Transfers `_value` amount of tokens from address `_from` to address `_to`, and MUST fire the `Transfer` event.
+
+The `transferFrom` method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf.
+This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies.
+The function SHOULD `throw` unless the `_from` account has deliberately authorized the sender of the message via some mechanism.
+
+*Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event.
+
+``` js
+function transferFrom(address _from, address _to, uint256 _value) returns (bool success)
+```
+
+
+
+#### approve
+
+Allows `_spender` to withdraw from your account multiple times, up to the `_value` amount. If this function is called again it overwrites the current allowance with `_value`.
+
+**NOTE**: To prevent attack vectors like the one [described here](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/) and discussed [here](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729),
+clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to `0` before setting it to another value for the same spender.
+THOUGH The contract itself shouldn't enforce it, to allow backwards compatilibilty with contracts deployed before
+
+``` js
+function approve(address _spender, uint256 _value) returns (bool success)
+```
+
+
+#### allowance
+
+Returns the amount which `_spender` is still allowed to withdraw from `_owner`.
+
+``` js
+function allowance(address _owner, address _spender) constant returns (uint256 remaining)
+```
+
+
+
+### Events
+
+
+#### Transfer
+
+MUST trigger when tokens are transferred, including zero value transfers.
+
+``` js
+event Transfer(address indexed _from, address indexed _to, uint256 _value)
+```
+
+
+
+#### Approval
+
+MUST trigger on any successful call to `approve(address _spender, uint256 _value)`.
+
+``` js
+event Approval(address indexed _owner, address indexed _spender, uint256 _value)
+```
+
+
+
+## Implementation
+
+There are already plenty of ERC20-compliant tokens deployed on the Ethereum network.
+Different implementations have been written by various teams that have different trade-offs: from gas saving to improved security.
+
+#### Example implementations are available at
+- https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol
+- https://github.com/ConsenSys/Tokens/blob/master/contracts/StandardToken.sol
+
+#### Implementation of adding the force to 0 before calling "approve" again:
+- https://github.com/Giveth/minime/blob/master/contracts/MiniMeToken.sol
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-706.md

@@ -0,0 +1,199 @@
+## Preamble
+
+    EIP: 706
+    Title: DEVp2p snappy compression
+    Author: Péter Szilágyi <peter@ethereum.org>
+    Type: Standard Track
+    Category: Networking
+    Status: Final
+    Created: 2017-09-07
+
+## Abstract
+The base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression. This results in a massive amount of bandwidth wasted in the entire network, making both initial sync as well as normal operation slower and laggier.
+
+This EIP proposes a tiny extension to the DEVp2p protocol to enable [Snappy compression](https://en.wikipedia.org/wiki/Snappy_(compression)) on all message payloads after the initial handshake. After extensive benchmarks, results show that data traffic is decreased by 60-80% for initial sync. You can find exact numbers below.
+
+## Motivation
+Synchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it's 55.89MB upload and 2.51GB download.
+
+However, most of this data (blocks, transactions) are heavily compressable. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network.
+
+The motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic.
+
+## Specification
+Bump the advertised DEVp2p version number from `4` to `5`. If during handshake, the remote side advertises support only for version `4`, run the exact same protocol as until now.
+
+If the remote side advertises a DEVp2p version `>= 5`, inject a Snappy compression step right before encrypting the DEVp2p message during sending:
+
+ * A message consists of `{Code, Size, Payload}`
+  * Compress the original payload with Snappy and store it in the same field.
+  * Update the message size to the length of the compressed payload.
+  * Encrypt and send the message as before, oblivious to compression.
+
+Similarly to message sending, when receiving a DEVp2p v5 message from a remote node, insert a Snappy decompression step right after the decrypting the DEVp2p message:
+
+* A message consists of `{Code, Size, Payload}`
+ * Decrypt the message payload as before, oblivious to compression.
+ * Decompress the payload with Snappy and store it in the same field.
+ * Update the message size to the length of the decompressed payload.
+
+Important caveats:
+
+ * The handshake message is **never** compressed, since it is needed to negotiate the common version.
+ * Snappy framing is **not** used, since the DEVp2p protocol already message oriented.
+
+*Note: Snappy supports uncompressed binary literals (up to 4GB) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (Snappy usually detects this case automatically).*
+
+### Avoiding DOS attacks
+
+Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindy decompress messages, since they may get significantly larger than 16MB.
+
+However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (*[the stream starts with the uncompressed length up to a maximum of `2^32 - 1` stored as a little-endian varint](https://github.com/google/snappy/blob/master/format_description.txt#L20)*). This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols.
+
+## Alternatives (discarded)
+
+**Alternative solutions to data compression that have been brought up and discarded are:**
+
+Extend protocol `xyz` to support compressed messages versus doing it at DEVp2p level:
+
+ * **Pro**: Can be better optimized when to compress and when not to.
+ * **Con**: Mixes in transport layer encoding into application layer logic.
+ * **Con**: Makes the individual message specs more convoluted with compression details.
+ * **Con**: Requires cross client coordination on every single protocol, making the effor much harder and repeated (eth, les, shh, bzz).
+
+Introduce seamless variations of protocol such as `xyz` expanded with `xyz-compressed`:
+
+ * **Pro**: Can be done (hacked in) without cross client coordination.
+ * **Con**: Litters the network with client specific protocol announces.
+ * **Con**: Needs to be specced in an EIP for cross interoperability anyway.
+
+**Other ideas that have been discussed and discarded:**
+
+Don't explicitly limit the decompressed message size, only the compressed one:
+
+ * **Pro**: Allows larger messages to traverse through DEVp2p.
+ * **Con**: Upper layer protocols need to check and discard large messages.
+ * **Con**: Needs lazy decompression to allow size limitations without DOS.
+
+## Backwards Compatibility
+This proposal is fully backward compatible. Clients upgrading to the proposed DEVp2p protocol version `5` should still support skipping the compression step for connections that only advertise version `4` of the DEVp2p protocol.
+
+## Implementation
+You can find a reference implementation of this EIP in https://github.com/ethereum/go-ethereum/pull/15106.
+
+## Test vectors
+
+There is more than one valid encoding of any given input, and there is more than one good internal compression algorithm within Snappy when trading off throughput for output size. As such, different implementations might produce slight variations in the compressed form, but all should be cross compatible between each other.
+
+As an example, take hex encoded RLP of block #272621 from the Rinkeby test network: [block.rlp (~3MB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.rlp).
+
+ * Encoding the raw RLP via [Go's Snappy library](https://github.com/golang/snappy) yields: [block.go.snappy (~70KB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.go.snappy).
+ * Encoding the raw RLP via [Python's Snappy library](https://github.com/andrix/python-snappy) yields: [block.py.snappy (~70KB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.py.snappy).
+
+You can verify that an encoded binary can be decoded into the proper plaintext using the following snippets:
+
+### Go
+
+```
+$ go get https://github.com/golang/snappy
+```
+
+```go
+package main
+
+import (
+	"bytes"
+	"encoding/hex"
+	"fmt"
+	"io/ioutil"
+	"log"
+	"os"
+
+	"github.com/golang/snappy"
+)
+
+func main() {
+	// Read and decode the decompressed file
+	plainhex, err := ioutil.ReadFile(os.Args[1])
+	if err != nil {
+		log.Fatalf("Failed to read decompressed file %s: %v", os.Args[1], err)
+	}
+	plain, err := hex.DecodeString(string(plainhex))
+	if err != nil {
+		log.Fatalf("Failed to decode decompressed file: %v", err)
+	}
+	// Read and decode the compressed file
+	comphex, err := ioutil.ReadFile(os.Args[2])
+	if err != nil {
+		log.Fatalf("Failed to read compressed file %s: %v", os.Args[2], err)
+	}
+	comp, err := hex.DecodeString(string(comphex))
+	if err != nil {
+		log.Fatalf("Failed to decode compressed file: %v", err)
+	}
+	// Make sure they match
+	decomp, err := snappy.Decode(nil, comp)
+	if err != nil {
+		log.Fatalf("Failed to decompress compressed file: %v", err)
+	}
+	if !bytes.Equal(plain, decomp) {
+		fmt.Println("Booo, decompressed file does not match provided plain text!")
+		return
+	}
+	fmt.Println("Yay, decompressed data matched provided plain text!")
+}
+```
+
+```
+$ go run main.go block.rlp block.go.snappy
+Yay, decompressed data matched provided plain text!
+
+$ go run main.go block.rlp block.py.snappy
+Yay, decompressed data matched provided plain text!
+```
+
+### Python
+
+```bash
+$ pip install python-snappy
+```
+
+```py
+import snappy
+import sys
+
+# Read and decode the decompressed file
+with open(sys.argv[1], 'rb') as file:
+    plainhex = file.read()
+
+plain = plainhex.decode("hex")
+
+# Read and decode the compressed file
+with open(sys.argv[2], 'rb') as file:
+    comphex = file.read()
+
+comp = comphex.decode("hex")
+
+# Make sure they match
+decomp = snappy.uncompress(comp)
+if plain != decomp:
+    print "Booo, decompressed file does not match provided plain text!"
+else:
+    print "Yay, decompressed data matched provided plain text!"
+```
+
+```
+$ python main.py block.rlp block.go.snappy
+Yay, decompressed data matched provided plain text!
+
+$ python main.py block.rlp block.py.snappy
+Yay, decompressed data matched provided plain text!
+```
+
+## References
+
+ * Snappy website: https://google.github.io/snappy/
+ * Snappy specification: https://github.com/google/snappy/blob/master/format_description.txt
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

README.md

@@ -10,24 +10,12 @@ First review [EIP-1](EIPS/eip-1.md). Then clone the repository and add your EIP
 * **Final** - an EIP that has been adopted in a previous hard fork (for Core/Consensus layer EIPs).
 * **Deferred** - an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
 
-# Accepted EIPs (planned for adoption)
+# Deferred EIPs (adoption postponed until the Constantinople Metropolis hard fork)
-| Number                                                  |Title                                                                                | Author                | Layer       | Status    |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------- | --------------------  | ------------| ----------|
-| [100](https://github.com/ethereum/EIPs/issues/100)      | Change difficulty adjustment to target mean block time including uncles             | Vitalik Buterin       | Core        | Accepted  |
-| [140](https://github.com/ethereum/EIPs/pull/206)        | REVERT instruction in the Ethereum Virtual Machine                                  | Beregszaszi, Mushegian| Core        | Accepted  |
-| [196](https://github.com/ethereum/EIPs/pull/213)        | Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 | Reitwiessner | Core        | Accepted  |
-| [197](https://github.com/ethereum/EIPs/pull/212)        | Precompiled contracts for optimal Ate pairing check on the elliptic curve alt_bn128 | Buterin, Reitwiessner | Core        | Accepted  |
-| [198](https://github.com/ethereum/EIPs/pull/198)        | Precompiled contract for bigint modular exponentiation                              | Vitalik Buterin       | Core        | Accepted  |
-| [211](https://github.com/ethereum/EIPs/pull/211)        | New opcodes: RETURNDATASIZE and RETURNDATACOPY                                      | Christian Reitwiessner| Core        | Accepted  |
-| [214](https://github.com/ethereum/EIPs/pull/214)        | New opcode STATICCALL                                                               | Buterin, Reitwiessner | Core        | Accepted  |
-| [649](https://github.com/ethereum/EIPs/pull/669)        | Metropolis Difficulty Bomb Delay and Block Reward Reduction                         | Schoedon, Buterin     | Core        | Accepted  |
-| [658](https://github.com/ethereum/EIPs/pull/658)        | Embedding transaction return data in receipts                                       | Nick Johnson          | Core        | Accepted  |
-
-# Deferred EIPs (adoption postponed)
 | Number                                                  |Title                                                                                | Author                | Layer       | Status    |
 | ------------------------------------------------------- | ----------------------------------------------------------------------------------- | --------------------  | ------------| ----------|
 | [86](https://github.com/ethereum/EIPs/pull/208)         | Abstraction of transaction origin and signature                                     | Vitalik Buterin       | Core        | Deferred  |
 | [96](https://github.com/ethereum/EIPs/pull/210)         | Blockhash refactoring                                                               | Vitalik Buterin       | Core        | Deferred  |
+| [145](EIPS/eip-145.md)                                  | Bitwise shifting instructions in EVM                        | Alex Beregszaszi, Paweł Bylica | Core        | Deferred   |
 
 # Finalized EIPs (standards that have been adopted)
 | Number                                                  |Title                                                        | Author          | Layer       | Status  |
@@ -36,9 +24,29 @@ First review [EIP-1](EIPS/eip-1.md). Then clone the repository and add your EIP
 | [6](EIPS/eip-6.md)                                      | Renaming Suicide Opcode                                     | Hudson Jameson  | Interface   | Final   |
 | [7](EIPS/eip-7.md)                                      | DELEGATECALL                                                | Vitalik Buterin | Core        | Final   |
 | [8](EIPS/eip-8.md)                                      | devp2p Forward Compatibility Requirements for Homestead     | Felix Lange     | Networking  | Final   |
+| [20](EIPS/eip-20-token-standard.md)                     | ERC-20 Token Standard                                       | Fabian Vogelsteller, Vitalik Buterin     | ERC  | Final   |
+| [55](EIPS/eip-55.md)                                    | ERC-55 Mixed-case checksum address encoding                 | Vitalik Buterin | Core        | Final   |
+| [100](https://github.com/ethereum/EIPs/issues/100)      | Change difficulty adjustment to target mean block time including uncles             | Vitalik Buterin       | Core        | Final  |
+| [137](EIPS/eip-137.md)                                  | Ethereum Domain Name Service - Specification                | Nick Johnson | ERC        | Final   |
+| [140](https://github.com/ethereum/EIPs/pull/206)        | REVERT instruction in the Ethereum Virtual Machine                                  | Beregszaszi, Mushegian| Core        | Final  |
 | [141](EIPS/eip-141.md)                                  | Designated invalid EVM instruction                          | Alex Beregszaszi| Core        | Final   |
 | [150](EIPS/eip-150.md)                                  | Gas cost changes for IO-heavy operations                    | Vitalik Buterin | Core        | Final   |
 | [155](EIPS/eip-155.md)                                  | Simple replay attack protection                             | Vitalik Buterin | Core        | Final   |
 | [160](EIPS/eip-160.md)                                  | EXP cost increase                                           | Vitalik Buterin | Core        | Final   |
 | [161](EIPS/eip-161.md)                                  | State trie clearing (invariant-preserving alternative)      | Gavin Wood | Core        | Final   |
+| [162](EIPS/eip-162.md)                                  | ERC-162 ENS support for reverse resolution of Ethereum addresses | Maurelian, Nick Johnson | ERC        | Final   |
 | [170](EIPS/eip-170.md)                                  | Contract code size limit                                    | Vitalik Buterin | Core        | Final   |
+| [181](EIPS/eip-181.md)                                  | ERC-181 ENS support for reverse resolution of Ethereum addresses | Nick Johnson | ERC        | Final   |
+| [190](EIPS/eip-190.md)                                  | ERC-190 Ethereum Smart Contract Packaging Standard          | Piper Merriam, Tim Coulter, Denis Erfurt (mhhf), RJ Catalano (VoR0220), Iuri Matias (iurimatias) | ERC        | Final   |
+| [196](https://github.com/ethereum/EIPs/pull/213)        | Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 | Reitwiessner | Core        | Final  |
+| [197](https://github.com/ethereum/EIPs/pull/212)        | Precompiled contracts for optimal Ate pairing check on the elliptic curve alt_bn128 | Buterin, Reitwiessner | Core        | Final  |
+| [198](https://github.com/ethereum/EIPs/pull/198)        | Precompiled contract for bigint modular exponentiation                              | Vitalik Buterin       | Core        | Final  |
+| [211](https://github.com/ethereum/EIPs/pull/211)        | New opcodes: RETURNDATASIZE and RETURNDATACOPY                                      | Christian Reitwiessner| Core        | Final  |
+| [214](https://github.com/ethereum/EIPs/pull/214)        | New opcode STATICCALL                                                               | Buterin, Reitwiessner | Core        | Final  |
+| [606](EIPS/eip-606.md)                                  | Hardfork Meta: Homestead                                    | Alex Beregszaszi | Meta         | Final    |
+| [607](EIPS/eip-607.md)                                  | Hardfork Meta: Spurious Dragon                              | Alex Beregszaszi | Meta         | Final    |
+| [608](EIPS/eip-608.md)                                  | Hardfork Meta: Tangerine Whistle                            | Alex Beregszaszi | Meta         | Final    |
+| [609](EIPS/eip-609.md)                                  | Hardfork Meta: Byzantium                                    | Alex Beregszaszi | Meta         | Final  |
+| [649](https://github.com/ethereum/EIPs/pull/669)        | Metropolis Difficulty Bomb Delay and Block Reward Reduction                         | Schoedon, Buterin     | Core        | Final  |
+| [658](https://github.com/ethereum/EIPs/pull/658)        | Embedding transaction return data in receipts                                       | Nick Johnson          | Core        | Final  |
+| [706](EIPS/eip-706.md)                                  | DEVp2p snappy compression                                   | Péter Szilágyi     | Networking  | Final   |