Merge pull request #3 from ethereum/master

Fast-forward upstream.

EIPS/eip-1010.md

@@ -0,0 +1,69 @@
+---
+eip: 1010
+title: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c
+author: Anderson Wesley (@andywesley)
+discussions-to: https://github.com/andywesley/EIPs/issues/1
+status: Draft
+type: Standards Track
+category: Core
+created: 2018-04-18
+---
+
+## Simple Summary
+
+This document proposes to improve the uniformity of ether distribution
+between wallet address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and
+wallet address `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` which are
+currently experiencing a significant non-uniformity.
+
+## Abstract
+
+As of the date of this EIP, the difference in balance between
+address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and address
+`0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` is far from equitable
+or uniform, with the former having more than 365,000 ether
+more than the latter. The distribution of ether between these two
+addresses must be improved in order to protect the Ethereum economy
+from centralized control. This will be accomplished by transferring
+100,000 ether from the former address to the latter. This is a properly
+motivated improvement in keeping with the core Ethereum philosophy of
+decentralization.
+
+## Motivation
+
+This proposal is necessary because the Ethereum protocol does not allow
+the owner of an address which does not own an equitable amount of ether
+to claim their share of ether from an address which owns a dangerously
+centralized quantity. Rather than proposing an overly complicated generic
+mechanism for any user to claim ether to which they believe they are
+equitably entitled, this proposal will take the simple route of a one-time
+transfer of 100,000 ether from `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B`
+to `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c`. This avoids duplicating
+the effort of other proposals and provides a net improvement to the
+Ethereum project and community.
+
+## Specification
+
+The balance of `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` will be decreased
+by 100,000 ether. The balance of `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c`
+will be increased by 100,000 ether. No net change in the amount of extant
+ether will occur unless at the time of implementation the former address does not
+contain sufficient ether for such a deduction.
+
+## Rationale
+
+The value 100,000 was chosen after careful technically sound analysis of various economic theories
+developed over the past century. In spite of the fact that it is a convenient round
+number, it is actually the exact output of a complex statistical process iterated to
+determine the optimal distribution of ether between these addresses.
+
+## Backwards Compatibility
+
+Clients that fail to implement this change will not be aware of the correct balances
+for these addresses. This will create a hard fork. The implementation of this change
+consistently among all clients as intended by the proposal process will be sufficient
+to ensure that backwards compatibility is not a concern.
+
+## Copyright
+Copyright and related rights waived via
+[CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1013.md

@@ -0,0 +1,33 @@
+---
+eip: 1013
+title: "Hardfork Meta: Constantinople"
+author: Nick Savers (@nicksavers)
+type: Meta
+status: Draft
+created: 2018-04-20
+requires: 145, 210
+---
+
+## Abstract
+
+This specifies the changes included in the hard fork named Constantinople.
+
+## Specification
+
+- Codename: Constantinople
+- Aliases: Metropolis/Constantinople, Metropolis part 2
+- Activation:
+  - Block >= TBD on Mainnet
+  - Block >= TBD on Ropsten testnet
+- Included EIPs:
+  - [EIP 145](./eip-145.md) (Bitwise shifting instructions in EVM)
+  - [EIP 210](./eip-210.md) (Blockhash refactoring)
+  - ...
+
+## References
+
+1. Links to Ethereum blog announcement and others
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

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-145.md

@@ -4,7 +4,7 @@ title: Bitwise shifting instructions in EVM
 author: Alex Beregszaszi, Paweł Bylica
 type: Standards Track
 category: Core
-status: Final
+status: Accepted
 created: 2017-02-13
 ---
 

EIPS/eip-165.md

@@ -4,7 +4,7 @@ title: ERC-165 Standard Interface Detection
 author: Christian Reitwießner <[email protected]>, Nick Johnson <[email protected]>, Fabian Vogelsteller <[email protected]>, Jordi Baylina <[email protected]>, Konrad Feldmeier <[email protected]>, William Entriken <[email protected]>
 type: Standards Track
 category: ERC
-status: Draft
+status: Final
 created: 2018-01-23
 ---
 

EIPS/eip-190.md

@@ -1,7 +1,7 @@
 ---
 eip: 190
 title: Ethereum Smart Contract Packaging Standard
-author: Piper Merriam, Tim Coulter, Denis Erfurt (mhhf), RJ Catalano (VoR0220), Iuri Matias (iurimatias)
+author: Piper Merriam (@pipermerriam), Tim Coulter (@tcoulter), Denis Erfurt (@mhhf), RJ Catalano (@VoR0220), Iuri Matias (@iurimatias)
 status: Final
 type: Standards Track
 category: ERC

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-198.md

@@ -101,4 +101,4 @@ The bit-based exponent calculation is done specifically to fairly charge for the
 
 # Copyright
 
-Copyright and related rights waived via CC0.
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-20.md

@@ -4,7 +4,7 @@ title: ERC-20 Token Standard
 author: Fabian Vogelsteller <[email protected]>, Vitalik Buterin <[email protected]>
 type: Standards Track
 category: ERC
-status: Accepted
+status: Final
 created: 2015-11-19
 ---
 

EIPS/eip-210.md

@@ -0,0 +1,86 @@
+---
+eip: 210
+title: Blockhash refactoring
+author: Vitalik Buterin (@vbuterin)
+type: Standards Track
+category: Core
+status: Draft
+created: 2017-02-10
+---
+
+### Summary
+
+Stores blockhashes in the state, reducing the protocol complexity and the need for client implementation complexity in order to process the BLOCKHASH opcode. Also extends the range of how far back blockhash checking can go, with the side effect of creating direct links between blocks with very distant block numbers, facilitating much more efficient initial light client syncing.
+
+### Parameters
+
+* `CONSTANTINOPLE_FORK_BLKNUM`: TBD
+* `SUPER_USER`: 2**160 - 2
+* `BLOCKHASH_CONTRACT_ADDR`: 0xf0 (ie. 240)
+* `BLOCKHASH_CONTRACT_CODE`: see below
+
+### Specification
+
+If `block.number == CONSTANTINOPLE_FORK_BLKNUM`, then when processing the block, before processing any transactions set the code of BLOCKHASH_CONTRACT_ADDR to BLOCKHASH_CONTRACT_CODE.
+
+If `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, then when processing a block, before processing any transactions execute a call with the parameters:
+
+* `SENDER`: SUPER_USER
+* `GAS`: 1000000
+* `TO`: BLOCKHASH_CONTRACT_ADDR
+* `VALUE`: 0
+* `DATA`: <32 bytes corresponding to the block's prevhash>
+
+If `block.number >= CONSTANTINOPLE_FORK_BLKNUM + 256`, then the BLOCKHASH opcode instead returns the result of executing a call (NOT a transaction) with the parameters:
+
+* `SENDER`: <account from which the opcode was called>
+* `GAS`: 1000000
+* `TO`: BLOCKHASH_CONTRACT_ADDR
+* `VALUE`: 0
+* `DATA`: 32 byte zero-byte-leftpadded integer representing the stack argument with which the opcode was called
+
+Also, for blocks where `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, the gas cost is increased from 20 to 800 to reflect the higher costs of processing the algorithm in the contract code.
+
+### BLOCKHASH_CONTRACT_CODE
+
+The Serpent source code is:
+
+```python
+with offset = 0:
+    if msg.sender == 0xfffffffffffffffffffffffffffffffffffffffe:
+        with bn = block.number - 1:
+            while 1:
+                ~sstore(offset + ~mod(bn, 256), ~calldataload(0))
+                if ~mod(bn, 256):
+                    ~stop()
+                bn = ~div(bn, 256)
+                offset += 256
+    elif ~calldataload(0) < block.number:
+        with tbn = ~calldataload(0):
+            with dist_minus_one = block.number - tbn - 1:
+                while dist_minus_one >= 256 && ~mod(tbn, 256) == 0:
+                    offset += 256
+                    tbn = ~div(tbn, 256) 
+                    dist_minus_one = ~div(dist_minus_one, 256)
+                if dist_minus_one >= 256:
+                    return(0)
+                return(~sload(offset + ~mod(tbn, 256)))
+    else:
+        return(0)
+```
+
+The EVM init code is:
+
+```
+0x6100e28061000e6000396100f056600073fffffffffffffffffffffffffffffffffffffffe33141561005957600143035b60011561005357600035610100820683015561010081061561004057005b6101008104905061010082019150610022565b506100e0565b4360003512156100d4576000356001814303035b61010081121515610085576000610100830614610088565b60005b156100a75761010083019250610100820491506101008104905061006d565b610100811215156100bd57600060a052602060a0f35b610100820683015460c052602060c0f350506100df565b600060e052602060e0f35b5b505b6000f3
+```
+
+The EVM bytecode that the contract code should be set to is:
+
+```
+0x600073fffffffffffffffffffffffffffffffffffffffe33141561005957600143035b60011561005357600035610100820683015561010081061561004057005b6101008104905061010082019150610022565b506100e0565b4360003512156100d4576000356001814303035b61010081121515610085576000610100830614610088565b60005b156100a75761010083019250610100820491506101008104905061006d565b610100811215156100bd57600060a052602060a0f35b610100820683015460c052602060c0f350506100df565b600060e052602060e0f35b5b50
+```
+
+### Rationale
+
+This removes the need for implementaitons to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols.

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-55.md

@@ -4,7 +4,7 @@ title: Mixed-case checksum address encoding
 author: Vitalik Buterin
 type: Standards Track
 category: ERC
-status: Accepted
+status: Final
 created: 2016-01-14
 ---
 

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
@@ -25,7 +24,7 @@ This specifies the changes included in the hard fork named Byzantium.
   - [EIP 140](./eip-140.md) (REVERT instruction in the Ethereum Virtual Machine)
   - [EIP 196](./eip-196.md) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)
   - [EIP 197](./eip-197.md) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)
-  - EIP 198 (Precompiled contract for bigint modular exponentiation)
+  - [EIP 198](./eip-198.md) (Precompiled contract for bigint modular exponentiation)
   - [EIP 211](./eip-211.md) (New opcodes: RETURNDATASIZE and RETURNDATACOPY)
   - [EIP 214](./eip-214.md) (New opcode STATICCALL)
   - [EIP 649](./eip-649.md) (Difficulty Bomb Delay and Block Reward Reduction)

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