status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-11 15:24:20 +00:00
Code Issues Projects Releases Wiki Activity

EIP-1: formatting fixes and clarifications (#2236)

Browse Source 
* EIP-1: make category field in EIP more clear

* Better heading in README

* EIP-2: fix typo in rendering

* EIP-1: clarify that an EIP can move from the Abandoned status to the Draft status

Also clarify that EIPs cannot move from the Rejected and Superseded states.

* EIP-1: rename WIP status to Idea

* EIP-1: change template formatting to fix markdown rendering

With angle brackets markdown renders them as HTML tags sometimes (depending on the rendering engine).

* EIP-1812: change copyright link to the correct CC0 link
This commit is contained in:
Alex Beregszaszi 2019-09-15 17:51:34 +01:00 committed by GitHub
parent aaea642106
commit 880184aa52
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 27 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
EIPS/eip-1.md
View File

@ -71,13 +71,13 @@ These calls generally result in a "rough consensus" around what EIPs should be i
Following is the process that a successful EIP will move along:
```
[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]
[ IDEA ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]
```
Each status change is requested by the EIP author and reviewed by the EIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your EIP. The EIP editors will process these requests as per the conditions below.
* **Active** -- 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).
* **Work in progress (WIP)** -- Once the champion has asked the Ethereum community whether an idea has any chance of support, they will write a draft EIP as a [pull request]. Consider including an implementation if this will aid people in studying the EIP.
* **Idea** -- Once the champion has asked the Ethereum community whether an idea has any chance of support, they will write a draft EIP as a [pull request]. Consider including an implementation if this will aid people in studying the EIP.
* :arrow_right: Draft -- If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP.
* :x: Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the [Ethereum philosophy](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy).
* **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
@ -94,9 +94,10 @@ Each status change is requested by the EIP author and reviewed by the EIP editor
Other exceptional statuses include:
* **Abandoned** -- This EIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore.
* **Rejected** -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented.
* **Active** -- This is similar to Final, but denotes an EIP which may be updated without changing its EIP number.
* **Superseded** -- An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP.
* :arrow_right: Draft -- Authors or new champions wishing to pursue this EIP can ask for changing it to Draft status.
* **Rejected** -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented. An EIP cannot move on from this state.
* **Active** -- This is similar to Final, but denotes an EIP which may be updated without changing its EIP number. An EIP cannot move on from this state.
* **Superseded** -- An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP. An EIP cannot move on from this state.
## What belongs in a successful EIP?
@ -122,33 +123,33 @@ Image files should be included in a subdirectory of the `assets` folder for that
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.
` 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:` <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.>
` author:` *a 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:` *a url pointing to the official discussion thread*
` status:` <Draft | Last Call | Accepted | Final | Active | Abandoned | Rejected | Superseded>
` status:` *Draft | Last Call | Accepted | Final | Active | Abandoned | Rejected | Superseded*
`* review-period-end:` <date review period ends>
`* review-period-end:` *date review period ends*
` type:` <Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
` type:` *Standards Track | Informational | Meta*
` * category:` <Core | Networking | Interface | ERC>
` * category:` *Core | Networking | Interface | ERC* (Standards Track EIPs only)
` created:` <date created on>
` created:` *date created on*
` * updated:` <comma separated list of dates>
` * updated:` *comma separated list of dates*
` * requires:` <EIP number(s)>
` * requires:` *EIP number(s)*
` * replaces:` <EIP number(s)>
` * replaces:` *EIP number(s)*
` * superseded-by:` <EIP number(s)>
` * superseded-by:` *EIP number(s)*
` * resolution:` \<a url pointing to the resolution of this EIP\>
` * resolution:` *a url pointing to the resolution of this EIP*
Headers that permit lists must separate elements with commas.

2
EIPS/eip-1812.md
View File

@ -439,4 +439,4 @@ There is a repo with a few example verifiers and consuming smart contracts writt
* [RevocationRegistry.sol](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/RevocationRegistry.sol)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/_).
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

2
EIPS/eip-2.md
View File

@ -27,7 +27,7 @@ If `block.number >= HOMESTEAD_FORK_BLKNUM`, do the following:
1. The gas cost *for creating contracts via a transaction* is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the `CREATE` opcode is unaffected.
2. All transaction signatures whose s-value is greater than `secp256k1n/2` are now considered invalid. The ECDSA recover precompiled contract remains unchanged and will keep accepting high s-values; this is useful e.g. if a contract recovers old Bitcoin signatures.
3. If contract creation does not have enough gas to pay for the final gas fee for adding the contract code to the state, the contract creation fails (i.e. goes out-of-gas) rather than leaving an empty contract.
4. Change the difficulty adjustment algorithm from the current formula: `block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2))` (where the ` + int(2**((block.number // 100000) - 2))` represents the exponential difficulty adjustment component) to `block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2))`, where `//` is the integer division operator, eg. `6 // 2 = 3`, `7 // 2 = 3`, `8 // 2 = 4`. The `minDifficulty` still defines the minimum difficulty allowed and no adjustment may take it below this.
4. Change the difficulty adjustment algorithm from the current formula: `block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2))` (where the `int(2**((block.number // 100000) - 2))` represents the exponential difficulty adjustment component) to `block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2))`, where `//` is the integer division operator, eg. `6 // 2 = 3`, `7 // 2 = 3`, `8 // 2 = 4`. The `minDifficulty` still defines the minimum difficulty allowed and no adjustment may take it below this.
# Rationale

5
README.md
View File

@ -1,4 +1,7 @@
# EIPs [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
# Ethereum Improvement Proposals (EIPs)
[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.
A browsable version of all current and draft EIPs can be found on [the official EIP site](https://eips.ethereum.org/).

2
eip-template.md
View File

@ -4,7 +4,7 @@ title: <EIP title>
author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
discussions-to: <URL>
status: Draft
type: <Standards Track (Core, Networking, Interface, ERC) | Meta | Informational>
type: <Standards Track | Meta | Informational>
category (*only required for Standard Track): <Core | Networking | Interface | ERC>
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
requires (*optional): <EIP number(s)>