Turn EIPs repository into a Github Pages / Jekyll site

.gitignore

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

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>

EIPS/eip-1.md

@@ -1,9 +1,11 @@
-    EIP: 1
-      Title: EIP Purpose and Guidelines
-      Status: Active
-      Type: Meta
-      Author: Martin Becze <[email protected]>, Hudson Jameson <[email protected]>
-      Created: 2015-10-27, 2017-02-01
+---
+eip: 1
+title: EIP Purpose and Guidelines
+status: Active
+type: Meta
+author: Martin Becze <[email protected]>, Hudson Jameson <[email protected]>
+created: 2015-10-27, 2017-02-01
+---
 
 What is an EIP?
 --------------
@@ -40,7 +42,7 @@ The EIP process begins with a new idea for Ethereum. It is highly recommended th
 
 Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.
 
-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. 
+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]. This gives the author a chance to continuously edit the draft EIP for proper formatting and quality. This also allows for further public comment and the author of the EIP to address concerns about the proposal.
 
@@ -60,7 +62,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:
 
-<img src=./eip-1/process.png>
+![](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).
 
@@ -115,29 +117,33 @@ EIPs should be written in [markdown] format. Image files should be included in a
 EIP Header Preamble
 -------------------
 
-Each EIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
+Each EIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens ('---'). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
 
-` EIP: ` <EIP number> (this is determined by the EIP editor)
+` eip: ` <EIP number> (this is determined by the EIP editor)
 
-` Title: `<EIP title>
+` title: `<EIP title>
 
-` Author: `<list of author's real names and optionally, email address>
+` author: `<list of author's real names and optionally, email address>
 
-` * Discussions-To: ` <email address>
+` * discussions-to: ` <email address>
 
-` Status: `<Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>
+` status: `<Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>
 
-` Type: `<Standards Track (Core, Networking, Interface, ERC)  | Informational | Process>
+` type: `<Standards Track (Core, Networking, Interface, ERC)  | Informational | Meta>
 
-` Created: `<date created on, in ISO 8601 (yyyy-mm-dd) format>
+` * category `: <Core | Networking | Interface | ERC>
 
-` * Replaces: `<EIP number>
+` created: `<date created on, in ISO 8601 (yyyy-mm-dd) format>
 
-` * Superseded-By: `<EIP number>
+` * requires: `<EIP number(s)>
 
-` * Resolution: `<url>
+` * replaces: `<EIP number(s)>
 
-The Author header lists the names, and optionally the email addresses of all the authors/owners of the EIP. The format of the Author header value must be
+` * superseded-by: `<EIP number(s)>
+
+` * resolution: `<url>
+
+The author header lists the names, and optionally the email addresses of all the authors/owners of the EIP. The format of the author header value must be
 
 Random J. User &lt;[email protected]&gt;
 
@@ -147,17 +153,21 @@ Random J. User
 
 if the email address is not given.
 
-Note: The Resolution header is required for Standards Track EIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the EIP is made.
+Note: The resolution header is required for Standards Track EIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the EIP is made.
+
+While an EIP is in private discussions (usually during the initial Draft phase), a discussions-to header will indicate the mailing list or URL where the EIP is being discussed. No discussions-to header is necessary if the EIP is being discussed privately with the author.
+
+The type header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).
 
-While an EIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the EIP is being discussed. No Discussions-To header is necessary if the EIP is being discussed privately with the author.
+The category header specifies the EIP's category. This is required for standards-track EIPs only.
 
-The Type header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).
+The created header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
 
-The Created header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
+EIPs may have a requires header, indicating the EIP numbers that this EIP depends on.
 
-EIPs may have a Requires header, indicating the EIP numbers that this EIP depends on.
+EIPs may also have a superseded-by header indicating that an EIP has been rendered obsolete by a later document; the value is the number of the EIP that replaces the current document. The newer EIP must have a Replaces header containing the number of the EIP that it rendered obsolete.
 
-EIPs may also have a Superseded-By header indicating that an EIP has been rendered obsolete by a later document; the value is the number of the EIP that replaces the current document. The newer EIP must have a Replaces header containing the number of the EIP that it rendered obsolete.
+Headers that permit lists must separate elements with commas.
 
 Auxiliary Files
 ---------------

EIPS/eip-100.md

@@ -1,12 +1,12 @@
-```
-EIP: 100
-Title: Change difficulty adjustment to target mean block time including uncles
-Author: Vitalik Buterin
-Type: Standard Track
-Category: Core
-Status: Final
-Created: 2016-04-28
-```
+---
+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
 

EIPS/eip-101.md

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

EIPS/eip-137.md

@@ -1,16 +1,16 @@
-<pre>
-  EIP: 137
-  Title: Ethereum Domain Name Service - Specification
-  Author: Nick Johnson <[email protected]>
-  Status: Final
-  Type: Standards Track
-  Category: ERC
-  Created: 2016-04-04
-</pre>
+---
+eip: 137
+title: Ethereum Domain Name Service - Specification
+author: Nick Johnson <[email protected]>
+status: Final
+type: Standards Track
+category: ERC
+created: 2016-04-04
+---
 
 # Abstract
 
-This draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes. 
+This draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes.
 
 The goal of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. In this way, users can enter a memorable string, such as 'vitalik.wallet' or 'www.mysite.swarm', and be directed to the appropriate resource. The mapping between names and resources may change over time, so a user may change wallets, a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, a browser may resolve 'mysite.swarm' to the IP address of its server by fetching its A (address) record, while a mail client may resolve the same address to a mail server by fetching its MX (mail exchanger) record.
 # Motivation

EIPS/eip-140.md

@@ -1,12 +1,12 @@
-## Preamble
-
-    EIP: 140
-    Title: REVERT instruction
-    Author: Alex Beregszaszi, Nikolai Mushegian ([email protected])
-    Type: Standard Track
-    Category: Core
-    Status: Final
-    Created: 2017-02-06
+---
+eip: 140
+title: REVERT instruction
+author: Alex Beregszaszi, Nikolai Mushegian ([email protected])
+type: Standards Track
+category: Core
+status: Final
+created: 2017-02-06
+---
 
 ## Simple Summary
 

EIPS/eip-141.md

@@ -1,12 +1,12 @@
-## Preamble
-
-    EIP: 141
-    Title: Designated invalid EVM instruction
-    Author: Alex Beregszaszi
-    Type: Standard Track
-    Category: Core
-    Status: Final
-    Created: 2017-02-09
+---
+eip: 141
+title: Designated invalid EVM instruction
+author: Alex Beregszaszi
+type: Standards Track
+category: Core
+status: Final
+created: 2017-02-09
+---
 
 ## Abstract
 

EIPS/eip-145.md

@@ -1,13 +1,12 @@
-## 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
-
+---
+eip: 145
+title: Bitwise shifting instructions in EVM
+author: Alex Beregszaszi, Paweł Bylica
+type: Standards Track
+category: Core
+status: Final
+created: 2017-02-13
+---
 
 ## Simple Summary
 
@@ -158,7 +157,7 @@ The newly introduced instructions have no effect on bytecode created in the past
     ---
     0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
     ```
-    
+
 
 ### `SHR` (logical shift right)
 

EIPS/eip-150.md

@@ -1,13 +1,13 @@
-## Preamble
-```
-EIP: 150
-Title: Gas cost changes for IO-heavy operations
-Author: Vitalik Buterin
-Type: Standard Track
-Category: Core
-Status: Final
-Created: 2016-09-24
-```
+---
+eip: 150
+title: Gas cost changes for IO-heavy operations
+author: Vitalik Buterin
+type: Standards Track
+category: Core
+status: Final
+created: 2016-09-24
+---
+
 ### Meta reference
 
 [Tangerine Whistle](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-608.md).

EIPS/eip-155.md

@@ -1,13 +1,12 @@
-## Preamble
-```
-EIP: 155
-Title: Simple replay attack protection
-Author: Vitalik Buterin
-Type: Standard Track
-Category: Core
-Status: Final
-Created: 2016-10-14
-```
+---
+eip: 155
+title: Simple replay attack protection
+author: Vitalik Buterin
+type: Standards Track
+category: Core
+status: Final
+created: 2016-10-14
+---
 
 ### Hard fork
 [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md)

EIPS/eip-158.md

@@ -1,13 +1,13 @@
-```
-EIP: 158
-Title: State clearing
-Author: Vitalik Buterin
-Type: Standard Track
-Category: Core
-Status: Superseded
-Created: 2016-10-16
-Superseded-By: 161
-```
+---
+eip: 158
+title: State clearing
+author: Vitalik Buterin
+type: Standards Track
+category: Core
+status: Superseded
+created: 2016-10-16
+superseded-by: 161
+---
 
 # Specification
 

EIPS/eip-160.md

@@ -1,12 +1,13 @@
-```
-EIP: 160
-Title: EXP cost increase
-Author: Vitalik Buterin
-Type: Standard Track
-Category: Core
-Status: Final
-Created: 2016-10-20
-```
+---
+eip: 160
+title: EXP cost increase
+author: Vitalik Buterin
+type: Standards Track
+category: Core
+status: Final
+created: 2016-10-20
+---
+
 ### Hard fork
 [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md)