Merge branch 'master' into eip777

.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,27 @@
+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'

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-X-authorisations-nickjohnson.md

@@ -0,0 +1,57 @@
+## Preamble
+
+    EIP: <to be assigned>
+    Title: Generalised authorisations
+    Author: Nick Johnson <nick@ethereum.org>
+    Type: Standard track
+    Category: ERC
+    Status: Draft
+    Created: 2018-03-12
+
+## Abstract
+This EIP specifies a generic authorisation mechanism, which can be used to implement a variety of authorisation patterns, replacing approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in a variety of other types of contract.
+
+## Motivation
+Smart contracts commonly need to provide an interface that allows a third-party caller to perform actions on behalf of a user. The most common example of this is token authorisations/operators, but other similar situations exist throughout the ecosystem, including for instance authorising operations on ENS domains. Typically each standard reinvents this system for themselves, leading to a large number of incompatible implementations of the same basic pattern. Here, we propose a generic method usable by all such contracts.
+
+The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub/ds-auth) and by OAuth.
+
+## Specification
+The generalised authorisation interface is implemented as a metadata provider, as specified in EIP-X-metadata-nickjohnson. The following mandatory function is implemented:
+
+```
+function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);
+```
+
+Where:
+ - `owner` is the owner of the resource. If approved the function call is treated as being made by this address.
+ - `caller` is the address making the present call.
+ - `callee` is the address of the contract being called.
+ - `func` is the 4-byte signature of the function being called.
+
+For example, suppose Alice authorises Bob to transfer tokens on her behalf. When Bob does so, Alice is the `owner`, Bob is the `caller`, the token contract is the `callee`, and the function signature for the transfer function is `func`.
+
+As this standard uses EIP-X-metadata-nickjohnson, the authorisation flow is as follows:
+
+ 1. The callee contract fetches the provider for the `owner` address from the metadata registry contract, which resides at a well-known address.
+ 2. The callee contract calls `canCall()` with the parameters described above. If the function returns false, the callee reverts execution.
+
+Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface:
+
+```
+function authoriseCaller(address owner, address caller, address callee, bytes4 func);
+function revokeCaller(address owner, address caller, address callee, bytes4 func);
+```
+
+Arguments have the same meaning as in `canCall`. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` or `revokeCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well.
+
+Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect.
+
+## Backwards Compatibility
+There are no backwards compatibility concerns.
+
+## Implementation
+Example implementation TBD.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/EIP-X-metadata-nickjohnson.md

@@ -0,0 +1,73 @@
+## Preamble
+
+    EIP: <to be assigned>
+    Title: Address metadata registry
+    Author: Nick Johnson <nick@ethereum.org>
+    Type: Standard track
+    Category: ERC
+    Status: Draft
+    Created: 2018-03-12
+    Dependencies: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
+
+## Abstract
+This EIP specifies a registry for address metadata, permitting both contracts and external accounts to supply metadata about themselves to onchain and offchain callers. This permits use-cases such as generalised authorisations, providing token acceptance settings, and claims registries.
+
+## Motivation
+An increasing set of use cases require storage of metadata associated with an address; see for instance EIP 777 and EIP 780, and the ENS reverse registry in EIP 181. Presently each use-case defines its own specialised registry. To prevent a proliferation of special-purpose registry contracts, we instead propose a single standardised registry using an extendable architecture that allows future standards to implement their own metadata standards.
+
+## Specification
+The metadata registry has the following interface:
+```
+interface AddressMetadataRegistry {
+  function provider(address target) view returns(address);
+  function setProvider(address _provider);
+}
+```
+
+`setProvider` specifies the metadata registry to be associated with the caller's address, while `provider` returns the address of the metadata registry for the supplied address.
+
+The metadata registry will be compiled with an agreed-upon version of Solidity and deployed using the trustless deployment mechanism to a fixed address that can be replicated across all chains.
+
+## Provider specification
+
+Providers may implement any subset of the metadata record types specified here. Where a record types specification requires a provider to provide multiple functions, the provider MUST implement either all or none of them. Providers MUST throw if called with an unsupported function ID.
+
+Providers have one mandatory function:
+
+```
+function supportsInterface(bytes4 interfaceID) constant returns (bool)
+```
+
+The `supportsInterface` function is documented in [EIP 165](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md), and returns true if the provider implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a provider returns `true` for `supportsInterface()`, it must implement the functions specified in that interface.
+
+`supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself.
+
+The first argument to all provider functions MUST be the address being queried; this facilitates the creation of multi-user provider contracts.
+
+Currently standardised provider interfaces are specified in the table below.
+
+| Interface name | Interface hash | Specification |
+| --- | --- | --- |
+
+EIPs may define new interfaces to be added to this registry.
+
+## Rationale
+There are two obvious approaches for a generic metadata registry: the indirection approach employed here, or a generalised key/value store. While indirection incurs the cost of an additional contract call, and requires providers to change over time, it also provides for significantly enhanced flexibility over a key/value store; for that reason we selected this approach.
+
+## Backwards Compatibility
+There are no backwards compatibility concerns.
+
+## Implementation
+The canonical implementation of the metadata registry is as follows:
+```
+contract AddressMetadataRegistry {
+  mapping(address=>address) public provider;
+  
+  function setProvider(address _provider) {
+    provider[msg.sender] = _provider;
+  }
+}
+```
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1.md

@@ -1,9 +1,11 @@
-    EIP: 1
-      Title: EIP Purpose and Guidelines
-      Status: Active
-      Type: Meta
-      Author: Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>
-      Created: 2015-10-27, 2017-02-01
+---
+eip: 1
+title: EIP Purpose and Guidelines
+status: Active
+type: Meta
+author: Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>
+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>
+![EIP Process](eip-1/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;address@dom.ain&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
 ---------------
@@ -210,10 +220,6 @@ Once the EIP is ready for the repository, the EIP editor will:
 
 <!-- -->
 
--   List the EIP in [README.md]
-
-<!-- -->
-
 -   Send a message back to the EIP author with next step.
 
 Many EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
@@ -229,6 +235,8 @@ December 7, 2016: EIP 1 has been improved and will be placed as a PR.
 
 February 1, 2016: EIP 1 has added editors, made draft improvements to process, and has merged with Master stream.
 
+March 21, 2018: Minor edits to accommodate new automatically-generated EIP directory on eips.ethereum.org.
+
   [EIP5]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5.md
   [EIP101]: https://github.com/ethereum/EIPs/issues/28
   [EIP90]: https://github.com/ethereum/EIPs/issues/90
@@ -256,7 +264,6 @@ February 1, 2016: EIP 1 has added editors, made draft improvements to process, a
   [formal specification]: https://github.com/ethereum/yellowpaper
   [the Issues section of this repository]: https://github.com/ethereum/EIPs/issues
   [markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
-  [README.md]: README.md "wikilink"
   [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips
   [Python's PEP-0001]: https://www.python.org/dev/peps/
 

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 <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