Merge branch 'master' of github.com:ethereum/EIPs into validated

EIPS/eip-1.md

@@ -6,7 +6,7 @@ type: Meta
 author: Martin Becze <[email protected]>, Hudson Jameson <[email protected]>, and others
         https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md
 created: 2015-10-27
-updated: 2015-12-07, 2016-02-01, 2018-03-21, 2018-05-29, 2018-10-17, 2019-05-19
+updated: 2015-12-07, 2016-02-01, 2018-03-21, 2018-05-29, 2018-10-17, 2019-05-19, 2019-12-04
 ---
 
 ## What is an EIP?
@@ -56,7 +56,7 @@ In addition to making sure your idea is original, it will be your role as the au
 
 For Core EIPs, given that they require client implementations to be considered **Final** (see "EIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your EIP. 
 
-The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda Github Issue].  
+The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda GitHub Issue].  
 
 The AllCoreDevs call serve as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.
 
@@ -118,6 +118,7 @@ Each EIP should have the following parts:
 - Backwards Compatibility - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
 - Test Cases - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
 - Implementations - The implementations must be completed before any EIP is given status “Final”, but it need not be completed before the EIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.
+- Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
 - Copyright Waiver - All EIPs must be in the public domain. See the bottom of this EIP for an example copyright waiver.
 
 ## EIP Formats and Templates
@@ -249,7 +250,7 @@ For each new EIP that comes in, an editor does the following:
 
 - Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
 - The title should accurately describe the content.
-- Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style
+- Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style
 
 If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
 
@@ -281,6 +282,8 @@ Oct 17, 2018: The `updated` header was introduced.
 
 May 19, 2019: The **Abandoned** status was introduced.
 
+Dec 4, 2019: The "Security Considerations" section was introduced.
+
 See [the revision history for further details](https://github.com/ethereum/EIPs/commits/master/EIPS/eip-1.md), which is also available by clicking on the History button in the top right of the EIP.
 
 ### Bibliography
@@ -314,7 +317,7 @@ See [the revision history for further details](https://github.com/ethereum/EIPs/
 [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips
 [Python's PEP-0001]: https://www.python.org/dev/peps/
 [the Ethereum Magicians forum]: https://ethereum-magicians.org/
-[AllCoreDevs agenda Github Issue]: https://github.com/ethereum/pm/issues
+[AllCoreDevs agenda GitHub Issue]: https://github.com/ethereum/pm/issues
 
 ## Copyright
 

EIPS/eip-1052.md

@@ -7,6 +7,7 @@ status: Final
 type: Standards Track
 category: Core
 created: 2018-05-02
+requires: 161
 ---
 
 ## Abstract
@@ -24,7 +25,7 @@ takes one argument from the stack, zeros the first 96 bits
 and pushes to the stack the keccak256 hash of the code of the account 
 at the address being the remaining 160 bits. 
 
-In case the account does not exist `0` is pushed to the stack.
+In case the account does not exist or is empty (as defined by [EIP-161](https://eips.ethereum.org/EIPS/eip-161)) `0` is pushed to the stack.
 
 In case the account does not have code the keccak256 hash of empty data
 (i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`)

EIPS/eip-1056.md

@@ -19,7 +19,7 @@ This ERC describes a standard for creating and updating identities with a limite
 
 ## Motivation
 
-As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC725](https://github.com/ethereum/EIPs/issues/725) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain.
+As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC725](https://eips.ethereum.org/EIPS/eip-725) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain.
 
 ## Definitions
 

EIPS/eip-1062.md

@@ -36,13 +36,13 @@ When mapping the IPFS base58 string to ENS resolver, first we convert the Base58
 ## Rationale
 To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below :
 
-```
+```solidity
 function setMultihash(bytes32 node, bytes hash) public only_owner(node);
 ```
 
 Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.
 
-```
+```solidity
 function multihash(bytes32 node) public view returns (bytes);
 ```
 
@@ -52,7 +52,7 @@ To implement the way to transfer from base58 to hex format and the reverse one,
 The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes)  
 To implement the method transfer from IPFS(Base58) to hex format :
 
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toHex = function(ipfsHash) {
@@ -63,7 +63,7 @@ export const toHex = function(ipfsHash) {
 
 To implement the method transfer from hex format to IPFS(Base58) :
 
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toBase58 = function(contentHash) {