Rebasing

.codespell-whitelist

@@ -0,0 +1,7 @@
+uint
+ith
+mitre
+readded
+crate
+developper
+ist

.gitignore

@@ -1,3 +1,4 @@
 _site
 .sass-cache
 .jekyll-metadata
+vendor

.travis-ci.sh

@@ -24,4 +24,6 @@ elif [[ $TASK = 'eip-validator' ]]; then
 
   FILES="$(ls EIPS/*.md | egrep "eip-[0-9]+.md")"
   bundle exec eip_validator $FILES
+elif [[ $TASK = 'codespell' ]]; then
+  codespell -q4 -I .codespell-whitelist eip-X.md EIPS/
 fi

.travis.yml

@@ -2,12 +2,15 @@ sudo: false # route your build to the container-based infrastructure for a faste
 
 language: ruby
 
+before_install:
+  - gem install bundler -v '< 2'
+
 cache:
   # Cache Ruby bundles
   - bundler
   - directories:
     - $TRAVIS_BUILD_DIR/tmp/.htmlproofer #https://github.com/gjtorikian/html-proofer/issues/381
-
+    - /usr/local/lib/python3.3/dist-packages/pip/
 
 # Assume bundler is being used, therefore
 # the `install` step will run `bundle install` by default.
@@ -20,14 +23,17 @@ env:
 matrix:
   fast_finish: true
   include:
-    - rvm: 2.2.5
+    - rvm: 2.3.0
       env: TASK='htmlproofer'
-    - rvm: 2.2.5
+    - rvm: 2.3.0
       env: TASK='htmlproofer-external'
-    - rvm: 2.2.5
+    - rvm: 2.3.0
       env: TASK='eip-validator'
+    - python: 3.3
+      env: TASK='codespell'
+      before_script: "sudo pip install urllib3[secure] && sudo pip install codespell"
   allow_failures:
-    - rvm: 2.2.5
+    - rvm: 2.3.0
       env: TASK='htmlproofer-external'
 
 notifications:

EIPS/eip-100.md

@@ -1,7 +1,7 @@
 ---
 eip: 100
 title: Change difficulty adjustment to target mean block time including uncles
-author: Vitalik Buterin
+author: Vitalik Buterin (@vbuterin)
 type: Standards Track
 category: Core
 status: Final

EIPS/eip-1011.md

@@ -183,7 +183,7 @@ def check_and_finalize_new_checkpoint(new_block):
         db.last_finalized_block = finalized_hash
 ```
 
-The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precendence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`.
+The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precedence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`.
 
 _Note_: If the client has no justified checkpoints, the contract returns `highest_justified_epoch` as `0` essentially reverting the fork choice rule to pure PoW.
 
@@ -379,7 +379,7 @@ Any call to this method fails prior to the end of the `WARM_UP_PERIOD`. Thus the
 #### Issuance
 A fixed amount of 1.25M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS.
 
-The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG.
+The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG.
 
 In addition to block rewards, miners now receive an issuance reward for including successful `vote` transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful `vote` transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract.
 

EIPS/eip-1013.md

@@ -3,9 +3,9 @@ eip: 1013
 title: "Hardfork Meta: Constantinople"
 author: Nick Savers (@nicksavers)
 type: Meta
-status: Draft
+status: Final
 created: 2018-04-20
-requires: 145, 1014, 1052, 1234, 1283
+requires: 145, 609, 1014, 1052, 1234, 1283
 ---
 
 ## Abstract
@@ -17,18 +17,21 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Cons
 - Codename: Constantinople
 - Aliases: Metropolis/Constantinople, Metropolis part 2
 - Activation:
-  - Block >= TBD on the Ethereum mainnet
-  - Block >= 4,230,000 on the Ropsten testnet
+  - `Block >= 7_280_000` on the Ethereum mainnet
+  - `Block >= 4,230,000` on the Ropsten testnet
+  - `Block >= 9_200_000` on the Kovan testnet
+  - `Block >= 3_660_663` on the Rinkeby testnet
 - Included EIPs:
-  - [EIP 145](./eip-145.md): Bitwise shifting instructions in EVM
-  - [EIP 1014](./eip-1014.md): Skinny CREATE2
-  - [EIP 1052](./eip-1052.md): EXTCODEHASH Opcode
-  - [EIP 1234](./eip-1234.md): Delay difficulty bomb, adjust block reward
-  - [EIP 1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps
+  - [EIP 145](https://eips.ethereum.org/EIPS/eip-145): Bitwise shifting instructions in EVM
+  - [EIP 1014](https://eips.ethereum.org/EIPS/eip-1014): Skinny CREATE2
+  - [EIP 1052](https://eips.ethereum.org/EIPS/eip-1052): EXTCODEHASH Opcode
+  - [EIP 1234](https://eips.ethereum.org/EIPS/eip-1234): Delay difficulty bomb, adjust block reward
+  - [EIP 1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps
 
 ## References
 
-The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev [Constantinople Session #1](https://github.com/ethereum/pm/issues/55). See also [Constantinople Progress Tracker](https://github.com/ethereum/pm/wiki/Constantinople-Progress-Tracker).
+1. The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev [Constantinople Session #1](https://github.com/ethereum/pm/issues/55). See also [Constantinople Progress Tracker](https://github.com/ethereum/pm/wiki/Constantinople-Progress-Tracker).
+2. https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/
 
 ## Copyright
 

EIPS/eip-1014.md

@@ -4,13 +4,13 @@ title: Skinny CREATE2
 author: Vitalik Buterin (@vbuterin)
 category: Core
 type: Standards Track
-status: Draft
+status: Final
 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 `keccak256( 0xff ++ address ++ salt ++ keccak256(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( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. 
 
 The `CREATE2` has the same `gas` schema as `CREATE`, but also an extra `hashcost` of `GSHA3WORD * ceil(len(init_code) / 32)`, to account for the hashing that must be performed. The `hashcost` is deducted at the same time as memory-expansion gas and `CreateGas` is deducted: _before_ evaluation of the resulting address and the execution of `init_code`.
 
@@ -52,7 +52,7 @@ With [EIP 161](https://eips.ethereum.org/EIPS/eip-161)
 
 > Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one
 
-This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself/ 
+This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself.
 
 It should also be noted that `SELFDESTRUCT` has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction. 
 

EIPS/eip-1015.md

@@ -12,7 +12,7 @@ created: 2018-04-20
 
 ## Simple Summary
 
-This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be mantained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance.
+This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance.
 
 ## Summary
 ### Thesis: many controversial issues boil down to resources
@@ -24,20 +24,20 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red
 
 #### Issuance Cap at 120 Million
 
-[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweight other actions. Burning ether is also a valid issuance decision.
+[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.
 
 #### Asics and advantadges of PoW
 
-[EIP 960](http://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
+[EIP 960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
 
 #### Recovery Forks
 
-After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](http://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
+After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](https://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
 
 
 #### Other Public Goods
 
-There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](http://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
+There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](https://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
 
 ## Proposed Solution
 ### Issuance Contract
@@ -52,7 +52,7 @@ It's not meant to be a general governance contract. The contract **should NOT be
 
 ##### It cannot only decrease issuance, and once decreased it cannot be increased again
 
-In order to reduce future abuse and uncertainity, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is agressively to reduce issuance to zero, it would take a known number of years.
+In order to reduce future abuse and uncertainty, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is aggressively to reduce issuance to zero, it would take a known number of years.
 
 ##### Results are locked for six months
 
@@ -109,7 +109,7 @@ A lot of things are suggested in this EIP, so I would like to propose these ques
 
 1. Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol?
 2. If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have?
-3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the proccess to add and remove them?
+3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them?
 
 
 

EIPS/eip-1052.md

@@ -3,7 +3,7 @@ eip: 1052
 title: EXTCODEHASH opcode
 author: Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>
 discussions-to: https://ethereum-magicians.org/t/extcodehash-opcode/262
-status: Draft
+status: Final
 type: Standards Track
 category: Core
 created: 2018-05-02