Separate transaction signer from transaction deployer

.gitignore

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

.travis-ci.sh

@@ -0,0 +1,19 @@
+#!/bin/bash
+set -e # halt script on error
+
+HTMLPROOFER_OPTIONS="./_site --internal-domains=eips.ethereum.org --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --url-ignore=/EIPS/eip-1,EIPS/eip-1,/EIPS/eip-107,/EIPS/eip-858"
+
+if [[ $TASK = 'htmlproofer' ]]; then
+  bundle exec jekyll doctor
+  bundle exec jekyll build
+  bundle exec htmlproofer $HTMLPROOFER_OPTIONS --disable-external
+elif [[ $TASK = 'htmlproofer-external' ]]; then
+  bundle exec jekyll doctor
+  bundle exec jekyll build
+  bundle exec htmlproofer $HTMLPROOFER_OPTIONS --external_only
+elif [[ $TASK = 'eip-validator' ]]; then
+  bundle exec eip_validator EIPS/*.md
+fi
+
+# Validate GH Pages DNS setup
+# bundle exec github-pages health-check

.travis.yml

@@ -0,0 +1,33 @@
+sudo: false # route your build to the container-based infrastructure for a faster build
+
+language: ruby
+
+# Cache Ruby bundles
+cache: bundler
+
+# Assume bundler is being used, therefore
+# the `install` step will run `bundle install` by default.
+script: "bash -ex .travis-ci.sh"
+
+env:
+  global:
+  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer
+
+matrix:
+  fast_finish: true
+  include:
+    - rvm: 2.2.5
+      env: TASK='htmlproofer'
+    - rvm: 2.2.5
+      env: TASK='htmlproofer-external'
+    - rvm: 2.2.5
+      env: TASK='eip-validator'
+  allow_failures:
+    - rvm: 2.2.5
+      env: TASK='htmlproofer-external'
+
+notifications:
+  webhooks:
+    urls:
+      - https://ethlab-183014.appspot.com/merge/
+    on_success: always

404.html

@@ -0,0 +1,24 @@
+---
+layout: default
+---
+
+<style type="text/css" media="screen">
+  .container {
+    margin: 10px auto;
+    max-width: 600px;
+    text-align: center;
+  }
+  h1 {
+    margin: 30px 0;
+    font-size: 4em;
+    line-height: 1;
+    letter-spacing: -1px;
+  }
+</style>
+
+<div class="container">
+  <h1>404</h1>
+
+  <p><strong>Page not found :(</strong></p>
+  <p>The requested page could not be found.</p>
+</div>

CNAME

@@ -0,0 +1 @@
+eips.ethereum.org

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: Standards Track
+category: Core
+status: Final
+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 >= BYZANTIUM_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-101.md

@@ -1,11 +1,12 @@
-### Title
-
-      EIP: 101
-      Title: Serenity Currency and Crypto Abstraction
-      Author: Vitalik Buterin <v@buterin.com>
-      Status: Active
-      Type: Serenity feature
-      Created: 2015-11-15
+---
+eip: 101
+title: Serenity Currency and Crypto Abstraction
+author: Vitalik Buterin <v@buterin.com>
+status: Draft
+type: Standards Track
+category: Core
+created: 2015-11-15
+---
 
 ### Specification
 

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/).