Merge branch 'master' into patch-3

.github/workflows/auto-merge-bot.yml

@@ -1,15 +1,10 @@
 on: [pull_request_target]
 name: Auto-Merge Bot
 jobs:
-  enable-auto-merge:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: alexwilson/enable-github-automerge-action@main
-      with:
-        github-token: ${{ secrets.TOKEN }}
   auto_merge_bot:
     runs-on: ubuntu-latest
     name: EIP Auto-Merge Bot
+    if: github.event.pull_request.draft == false
     steps:
       - name: Checkout
         uses: actions/checkout@v2
@@ -18,8 +13,21 @@ jobs:
         with:
           node-version: '14'
       - name: auto-merge-bot
-        uses: ethereum/EIP-Bot@b6cf981087e888b5d7fbd4726458c453f8491532 # master
+        uses: ethereum/EIP-Bot@d627d305e33d8cdfe0310588ba74670d4a882600 # master
         id: auto-merge-bot
         with:
           GITHUB-TOKEN: ${{ secrets.TOKEN }} 
           MERGE_ENABLED: false
+          CORE_EDITORS: "@MicahZoltu,@lightclient,@axic"
+          ERC_EDITORS: "@lightclient,@axic"
+          NETWORKING_EDITORS: "@MicahZoltu,@lightclient,@axic"
+          INTERFACE_EDITORS: "@lightclient,@axic"
+          META_EDITORS: "@lightclient,@axic"
+          INFORMATIONAL_EDITORS: "@lightclient,@axic"
+  enable-auto-merge:
+    runs-on: ubuntu-latest
+    needs: ["auto_merge_bot"]
+    steps:
+    - uses: alexwilson/enable-github-automerge-action@1.0.0
+      with:
+        github-token: ${{ secrets.TOKEN }}

.github/workflows/auto-stagnate-bot.yml

@@ -16,7 +16,7 @@ jobs:
         with:
           node-version: '14'
       - name: auto-stagnant-bot
-        uses: ethereum/EIP-Bot@695e64c194456ebde5b9a102adc7443958bd364a # mark-eips-stale
+        uses: ethereum/EIP-Bot@b3ac0ba3600aea27157fc68d1e36c08cc5a6db77 # mark-eips-stale
         id: auto-stagnant-bot
         with:
           GITHUB-TOKEN: ${{ secrets.TOKEN }}

.github/workflows/greetings.yml

@@ -9,5 +9,5 @@ jobs:
     - uses: actions/first-interaction@v1
       with:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
-        issue-message: 'Since this is your first issue, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.'
-        pr-message: 'Since this is your first pull request, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.'
+        issue-message: 'Since this is your first issue, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.\n\nIf this issue was created as a “discussions-to” for an EIP or to discuss an idea for an EIP, please close it and create a thread at [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/).'
+        pr-message: 'Since this is your first pull request, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.\n\nIf this issue was created as a “discussions-to” for an EIP or to discuss an idea for an EIP, please close it and create a thread at [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/).'

.github/workflows/manual-bot-rerun.yml

@@ -0,0 +1,35 @@
+name: Manual Bot Rerun
+on:
+  workflow_dispatch:
+    inputs:
+      pullRequestNumber:
+        description: "PR number (with the run you'd like to re-run)"
+        required: true
+      eventType:
+        description: "event type (of the run you want to re-run)"
+        required: true
+        default: "pull_request_target"
+      idOfBotWorkflow:
+        description: "id of the bot workflow (just leave as default if you don't know)"
+        required: true
+        default: "6519716"
+
+jobs:
+  rerun-bot:
+    runs-on: ubuntu-latest
+    name: Manual Bot Rerun
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Setup Node.js Environment
+        uses: actions/setup-node@v2
+        with:
+          node-version: '14'
+      - name: rerun-workflow
+        uses: ethereum/EIP-Bot@90d0591e71314dc1430c6cde91bb787e185e0b4b # manual-bot-rerun
+        id: rerun-workflow
+        with:
+          GITHUB-TOKEN: ${{ secrets.TOKEN }}
+          PULL-NUMBER: ${{github.event.inputs.pullRequestNumber }}
+          ID-TO-RERUN: ${{ github.event.inputs.idOfBotWorkflow }}
+          EVENT-TYPE: ${{ github.event.inputs.eventType }}

.github/workflows/rerun-bot-workflow-run.yml

@@ -18,8 +18,10 @@ jobs:
         with:
           node-version: '14'
       - name: auto-merge-bot
-        uses: ethereum/EIP-Bot@983960684e010eb6ad6e7bd168169e4d57a17cf8 # rerun-pull-request-target-on-review 
+        uses: ethereum/EIP-Bot@1f05ace5691062379bd910aa27402eecb8f295ac # rerun-pull-request-target-on-review 
         id: rerun-auto-merge-bot
         with:
           GITHUB-TOKEN: ${{ secrets.TOKEN }}
           WORKFLOW-ID: ${{github.event.workflow_run.id}}
+          ID-TO-RERUN: "6519716"
+          RUN-EVENT-TYPE: "pull_request_target"

.github/workflows/stale.yml

@@ -1,19 +1,33 @@
-name: "Mark stale PRs"
+name: "Mark stale PRs & Issues"
 
 on:
   schedule:
   # Run this every hour, so we are not spammed with changes at once. Later we could consider changing this to once a day.
   - cron: "0 * * * *"
 
 jobs:
-  stale:
+  stale-pr:
     runs-on: ubuntu-latest
+    name: "Mark stale PRs"
     steps:
     - uses: actions/stale@v3
       with:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
-        stale-pr-message: 'There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.'
-        close-pr-message: 'This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.'
         days-before-stale: 60
         days-before-close: 7
         stale-pr-label: 'stale'
+        stale-pr-message: 'There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.'
+        close-pr-message: 'This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.'
+  stale-issue:
+    runs-on: ubuntu-latest
+    name: "Mark stale issues"
+    steps:
+    - uses: actions/stale@v3
+      with:
+        repo-token: ${{ secrets.GITHUB_TOKEN }}
+        days-before-stale: 180
+        days-before-close: 14
+        exempt-issue-labels: 'discussions-to'
+        stale-issue-label: 'stale'
+        stale-issue-message: 'There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.'
+        close-issue-message: 'This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.'

.travis.yml

@@ -30,7 +30,7 @@ matrix:
     - language: rust
       cache: cargo
       before_script:
-        - cargo install eipv --version=0.2.0
+        - cargo install eipv --version=0.4.0
       env: TASK='eip-validator'
     - python: 3.3
       env: TASK='codespell'

EIPS/eip-1.md

@@ -70,21 +70,21 @@ These calls generally result in a "rough consensus" around what EIPs should be i
 
 The following is the standardization process for all EIPs in all tracks:
 
-![EIP Status Diagram](../assets/eip-1/EIP-process.png)
+![EIP Status Diagram](../assets/eip-1/EIP-process-update.jpg)
 
 **Idea** - An idea that is pre-draft. This is not tracked within the EIP Repository.
 
 **Draft** - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
 
 **Review** - An EIP Author marks an EIP as ready for and requesting Peer Review.
 
-**Last Call** - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later.
+**Last Call** - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (`last-call-deadline`), typically 14 days later.
 
 If this period results in necessary normative changes it will revert the EIP to `REVIEW`.
 
 **Final** - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
 
-**Stagnant** - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is moved to `STAGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `DRAFT`.
+**Stagnant** - Any EIP in `DRAFT` or `REVIEW` or `LAST CALL` if inactive for a period of 6 months or greater is moved to `STAGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `DRAFT` or it's earlier status. If not resurrected, a proposal may stay forever in the this status. 
 
 >*EIP Authors are notified of any algorithmic change to the status of their EIP*
 
@@ -113,37 +113,31 @@ EIPs should be written in [markdown] format. There is a [template](https://githu
 
 ## EIP Header Preamble
 
-Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). 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](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.
 
 ` eip:` *EIP number* (this is determined by the EIP editor)
 
 ` title:` *The EIP title is a few words, not a complete sentence*
 
 ` description:` *Description is one full (short) sentence*
 
-` author:` *a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.*
+` author:` *The list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.*
 
-` * discussions-to:` *a url pointing to the official discussion thread*
+` discussions-to:` *The url pointing to the official discussion thread*
 
 ` status:` *Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living*
 
-` * review-period-end:` *date review period ends*
+` last-call-deadline:` *The date last call period ends on* (Optional field, only needed when status is `Last Call`)
 
-` type:` *Standards Track, Meta, or Informational*
+` type:` *One of `Standards Track`, `Meta`, or `Informational`*
 
-` * category:` *Core, Networking, Interface, or ERC* (fill out for Standards Track EIPs only)
+` category:` *One of `Core`, `Networking`, `Interface`, or `ERC`* (Optional field, only needed for `Standards Track` EIPs)
 
-` created:` *date created on*
+` created:` *Date the EIP was created on*
 
-` * updated:` *comma separated list of dates*
+` requires:` *EIP number(s)* (Optional field)
 
-` * requires:` *EIP number(s)*
-
-` * replaces:` *EIP number(s)*
-
-` * superseded-by:` *EIP number(s)*
-
-` * resolution:` *a url pointing to the resolution of this EIP*
+` withdrawal-reason:` *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`)
 
 Headers that permit lists must separate elements with commas.
 
@@ -169,15 +163,11 @@ It is not possible to use both an email and a GitHub username at the same time.
 
 At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them.
 
-#### `resolution` header
-
-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.
-
 #### `discussions-to` header
 
-While an EIP is a draft, a `discussions-to` header will indicate the mailing list or URL where the EIP is being discussed. As mentioned above, an example of a place to discuss your EIP is [Ethereum Magicians](https://ethereum-magicians.org/) (this is suitable for EIPs that may be contentious or have a strong governance aspect).
+While an EIP is a draft, a `discussions-to` header will indicate the URL where the EIP is being discussed.
 
-As an exception, `discussions-to` cannot point to GitHub pull requests.
+The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).
 
 #### `type` header
 
@@ -191,18 +181,10 @@ The `category` header specifies the EIP's category. This is required for standar
 
 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.
 
-#### `updated` header
-
-The `updated` header records the date(s) when the EIP was updated with "substantial" changes. This header is only valid for EIPs of Draft and Active status.
-
 #### `requires` header
 
 EIPs may have a `requires` header, indicating the EIP numbers that this EIP depends on.
 
-#### `superseded-by` and `replaces` headers
-
-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.
-
 ## Linking to other EIPs
 
 References to other EIPs should follow the format `EIP-N` where `N` is the EIP number you are referring to.  Each EIP that is referenced in an EIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompanied by a link on subsequent references.  The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc.  For example, you would link to this EIP with `[EIP-1](./eip-1.md)`.
@@ -221,16 +203,19 @@ If you are interested in assuming ownership of an EIP, send a message asking to
 
 The current EIP editors are
 
-- Nick Johnson (@arachnid)
+- Alex Beregszaszi (@axic)
+- Matt Garnett (@lightclient)
+- Micah Zoltu (@MicahZoltu)
+- Greg Colvin (@gcolvin)
+
+Emeritus EIP editors are 
+
 - Casey Detrio (@cdetrio)
-- Hudson Jameson (@Souptacular)
+- Nick Johnson (@arachnid)
 - Vitalik Buterin (@vbuterin)
+- Hudson Jameson (@Souptacular)
 - Nick Savers (@nicksavers)
 - Martin Becze (@wanderer)
-- Greg Colvin (@gcolvin)
-- Alex Beregszaszi (@axic)
-- Micah Zoltu (@MicahZoltu)
-- Matt Garnett (@lightclient)
 
 ## EIP Editor Responsibilities
 
@@ -256,8 +241,16 @@ The editors don't pass judgment on EIPs. We merely do the administrative & edito
 
 ## Style Guide
 
+### EIP numbers
+
 When referring to an EIP by number, it should be written in the hyphenated form `EIP-X` where `X` is the EIP's assigned number.
 
+### RFC 2119
+
+EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section:
+
+> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+
 ## History
 
 This document was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors.

EIPS/eip-101.md

@@ -2,7 +2,7 @@
 eip: 101
 title: Serenity Currency and Crypto Abstraction
 author: Vitalik Buterin <v@buterin.com>
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2015-11-15

EIPS/eip-1010.md

@@ -3,7 +3,7 @@ eip: 1010
 title: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c
 author: Anderson Wesley (@andywesley)
 discussions-to: https://github.com/andywesley/EIPs/issues/1
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2018-04-18

EIPS/eip-1011.md

@@ -1,7 +1,7 @@
 ---
 eip: 1011
 title: Hybrid Casper FFG
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 author: Danny Ryan (@djrtwo), Chih-Cheng Liang (@ChihChengLiang)

EIPS/eip-1015.md

@@ -3,7 +3,7 @@ eip: 1015
 title: Configurable On Chain Issuance
 author: Alex Van de Sande <avsa@ethereum.org>
 discussions-to: https://ethereum-magicians.org/t/eip-dynamic-block-rewards-with-governance-contract/204
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2018-04-20

EIPS/eip-1046.md

@@ -3,7 +3,7 @@ eip: 1046
 title: ERC20 Metadata Extension
 author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs)
 discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfh1g/erc20_metadata_extension_eip_1046/
-status: Draft
+status: Stagnant
 type: Standards Track
 category: ERC
 created: 2018-04-13

EIPS/eip-1051.md

@@ -3,7 +3,7 @@ eip: 1051
 title: Overflow checking for the EVM
 author: Nick Johnson <arachnid@notdot.net>
 discussions-to: https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261
-status: Draft
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2018-05-02

EIPS/eip-1056.md

@@ -5,7 +5,7 @@ author: Pelle Braendgaard <pelle.braendgaard@consensys.net>, Joel Torstensson <o
 type: Standards Track
 category: ERC
 discussions-to: https://github.com/ethereum/EIPs/issues/1056
-status: Draft
+status: Stagnant
 created: 2018-05-03
 ---
 

EIPS/eip-1057.md

@@ -3,7 +3,7 @@ eip: 1057
 title: ProgPoW, a Programmatic Proof-of-Work
 author: Greg Colvin <greg@colvin.org>, Andrea Lanfranchi (@AndreaLanfranchi), Michael Carter (@bitsbetrippin), IfDefElse <ifdefelse@protonmail.com>
 discussions-to: https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272
-status: Review
+status: Stagnant
 type: Standards Track
 category: Core
 created: 2018-05-02

EIPS/eip-1062.md

@@ -3,7 +3,7 @@ eip: 1062
 title: Formalize IPFS hash into ENS(Ethereum Name Service) resolver
 author: Phyrex Tsai <phyrex@portal.network>, Portal Network Team
 discussions-to: https://ethereum-magicians.org/t/eip-1062-formalize-ipfs-hash-into-ens-ethereum-name-service-resolver/281
-status: Draft
+status: Stagnant
 type: Standards Track
 category: ERC
 created: 2018-05-02

EIPS/eip-1066.md

@@ -3,7 +3,7 @@ eip: 1066
 title: Status Codes
 author: Brooklyn Zelenka (@expede), Tom Carchrae (@carchrae), Gleb Naumenko (@naumenkogs)
 discussions-to: https://ethereum-magicians.org/t/erc-1066-ethereum-status-codes-esc/
-status: Draft
+status: Stagnant
 type: Standards Track
 category: ERC
 created: 2018-05-05