Merge branch 'bls_keystore' of github.com:CarlBeek/EIPs into bls_keystore

* 'bls_keystore' of github.com:CarlBeek/EIPs: (47 commits)
  fix link to heading
  Fix spelling
  Fix email address
  Draft EIP: BLS12-381 Deterministic Account Hierarchy (ethereum#2334)
  Fix some URLs and require 2333 too
  Add name to metadata title (ethereum#2370)
  Draft: BLS12-381 Key Generation (ethereum#2333)
  Automatically merged updates to draft EIP(s)  (ethereum#2397)
  Hard fork proposal to address the Ice age (ethereum#2387)
  Automatically merged updates to draft EIP(s) 1767 (ethereum#2262)
  EIP-2021: Payoutable Token (ethereum#2021)
  EIP-2009: Compliance Service (ethereum#2009)
  EIP-2019: Fundable Token (ethereum#2019)
  Use solidity/javascript highlighting in various EIPs (ethereum#2372)
  EIP-2018: Clearable Token (ethereum#2018)
  EIP-1996: Holdable token (ethereum#1996)
  Fix the username of @pizza-r0b in EIP-2309 (ethereum#2389)
  Clarify that empty accounts also return 0 in EIP-1052 (ethereum#2388)
  dType Functions Extension - Decentralized Type System for EVM (ethereum#2267)
  Fix spelling of GitHub [R4R] (ethereum#2369)
  ...

Author: CarlBeek

EIPS/eip-1.md

@@ -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.
 
@@ -249,7 +249,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.
 
@@ -314,7 +314,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-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) {

EIPS/eip-1077.md

@@ -51,7 +51,7 @@ In order to be compliant, the transaction **MUST** request to sign a messageHash
 
 The fields **MUST** be concatenated in this order:
 
-```
+```solidity
 keccak256(
     byte(0x19),
     byte(0),

EIPS/eip-1108.md

@@ -3,7 +3,7 @@ eip: 1108
 title: Reduce alt_bn128 precompile gas costs
 author: Antonio Salazar Cardozo (@shadowfiend), Zachary Williamson (@zac-williamson)
 discussions-to: https://ethereum-magicians.org/t/eip-1108-reduce-alt-bn128-precompile-gas-costs/3206
-status: Draft
+status: Final
 type: Standards Track
 category: Core
 created: 2018-05-21

EIPS/eip-1132.md

@@ -43,7 +43,7 @@ The intention with this proposal is to enhance the ERC20 standard with token-loc
 I’ve extended the ERC20 interface with the following enhancements:
 
 ### Locking of tokens
-```
+```solidity
 /**
   * @dev Locks a specified amount of tokens against an address,
   *      for a specified reason and time
@@ -55,7 +55,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason
@@ -67,7 +67,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility at a future timestamp
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason at a specific time
@@ -80,7 +80,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens held by an address
-```
+```solidity
 /**
   * @dev @dev Returns total tokens held by an address (locked + transferable)
   * @param _of The address to query the total balance of
@@ -89,7 +89,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Extending lock period
-```
+```solidity
 /**
   * @dev Extends lock for a specified reason and time
   * @param _reason The reason to lock tokens
@@ -99,7 +99,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Increasing number of tokens locked
-```
+```solidity
 /**
   * @dev Increase number of tokens locked for a specified reason
   * @param _reason The reason to lock tokens
@@ -108,7 +108,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function increaseLockAmount(bytes32 _reason, uint256 _amount) public returns (bool)
 ```
 ### Fetching number of unlockable tokens under each utility
-```
+```solidity
 /**
   * @dev Returns unlockable tokens for a specified address for a specified reason
   * @param _of The address to query the the unlockable token count of
@@ -117,15 +117,15 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
  ```    
 ### Fetching number of unlockable tokens
-```
+```solidity
 /**
   * @dev Gets the unlockable tokens of a specified address
   * @param _of The address to query the the unlockable token count of
   */
   function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
 ```
 ### Unlocking tokens
-```
+```solidity
 /**
   * @dev Unlocks the unlockable tokens of a specified address
   * @param _of Address of user, claiming back unlockable tokens

EIPS/eip-1155.md

@@ -700,7 +700,7 @@ Another simple way to represent non-fungibles is to allow a maximum value of 1 f
 - [The Sandbox - Dual ERC-1155/721 Contract](https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset)
 
 **Articles & Discussions**
-- [Github - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
+- [GitHub - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
 - [ERC-1155 - The Crypto Item Standard](https://blog.enjincoin.io/erc-1155-the-crypto-item-standard-ac9cf1c5a226)
 - [Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%](https://medium.com/horizongames/going-beyond-erc20-and-erc721-9acebd4ff6ef)
 - [Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More](https://blockonomi.com/erc1155-gaming-token/)

EIPS/eip-1191.md

@@ -2,22 +2,31 @@
 eip: 1191 
 title: Add chain id to mixed-case checksum address encoding 
 author: Juliano Rizzo (@juli)
-status: Draft
+status: Last Call
+review-period-end: 2019-11-18
 type: Standards Track
 category: ERC
 created: 2018-03-18
 requires: 55, 155
 discussions-to: https://github.com/ethereum/EIPs/issues/1121
 ---
+
 ## Simple Summary
 This EIP extends EIP-55 by optionally adding a chain id defined by EIP-155 to the checksum calculation.
 
+## Abstract
+The EIP-55 was created to prevent users from losing funds by sending them to invalid addresses. This EIP extends EIP-55 to protect users from losing funds by sending them to addresses that are valid but that where obtained from a client of another network.For example, if this EIP is implemented, a wallet can alert the user that is trying to send funds to an Ethereum Testnet address from an Ethereum Mainnet wallet.  
+
+## Motivation
+The motivation of this proposal is to provide a mechanism to allow software to distinguish addresses from different Ethereum based networks. This proposal is necessary because Ethereum addresses are hashes of public keys and do not include any metadata. By extending the EIP-55 checksum algorithm it is possible to achieve this objective.
+
 ## Specification
 Convert the address using the same algorithm defined by EIP-55 but if a registered chain id is provided, add it to the input of the hash function. If the chain id passed to the function belongs to a network that opted for using this checksum variant, prefix the address with the chain id and the `0x` separator before calculating the hash. Then convert the address to hexadecimal, but if the ith digit is a letter (ie. it's one of `abcdef`) print it in uppercase if the 4*ith bit of the calculated hash is 1 otherwise print it in lowercase.
 
 ## Rationale 
  Benefits:
  - By means of a minimal code change on existing libraries, users are protected from losing funds by mixing addresses of different Ethereum based networks.
+
 ## Backwards Compatibility
 This proposal is fully backward compatible. The checksum calculation is changed only for new networks that choose to adopt this EIP and add their chain numbers to the Adoption Table included in this document.
 
@@ -37,43 +46,53 @@ def eth_checksum_encode(addr, chainid=1):
     out = addr[:2] + ''.join([c.upper() if int(a,16) >= 8 else c for c,a in aggregate])
     return out
 ```
+
 ## Test Cases
 ```python
-eth_mainnet= [
-'0x88021160C5C792225E4E5452585947470010289D',
-'0x27b1fdb04752bbc536007a920d24acb045561c26',
-'0x52908400098527886E0F7030069857D2E4169EE7',
-'0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed',
-'0x8617E340B3D01FA5F11F306F4090FD50E238070D',
-'0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb',
-'0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB',
-'0xde709f2102306220921060314715629080e2fb77',
-'0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359',
+eth_mainnet = [
+"0x27b1fdb04752bbc536007a920d24acb045561c26",
+"0x3599689E6292b81B2d85451025146515070129Bb",
+"0x42712D45473476b98452f434e72461577D686318",
+"0x52908400098527886E0F7030069857D2E4169EE7",
+"0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed",
+"0x6549f4939460DE12611948b3f82b88C3C8975323",
+"0x66f9664f97F2b50F62D13eA064982f936dE76657",
+"0x8617E340B3D01FA5F11F306F4090FD50E238070D",
+"0x88021160C5C792225E4E5452585947470010289D",
+"0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb",
+"0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB",
+"0xde709f2102306220921060314715629080e2fb77",
+"0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359",
 ]
 rsk_mainnet = [
-'0x6549F4939460DE12611948B3F82B88C3C8975323',
-'0x27b1FdB04752BBc536007A920D24ACB045561c26',
-'0x3599689E6292B81B2D85451025146515070129Bb',
-'0x52908400098527886E0F7030069857D2E4169ee7',
-'0x5aaEB6053f3e94c9b9a09f33669435E7ef1bEAeD',
-'0x8617E340b3D01Fa5f11f306f4090fd50E238070D',
-'0xD1220A0Cf47c7B9BE7a2e6ba89F429762E7B9adB',
-'0xDBF03B407c01E7CD3cBea99509D93F8Dddc8C6FB',
-'0xDe709F2102306220921060314715629080e2FB77',
-'0xFb6916095cA1Df60bb79ce92cE3EA74c37c5d359',
+"0x27b1FdB04752BBc536007A920D24ACB045561c26",
+"0x3599689E6292B81B2D85451025146515070129Bb",
+"0x42712D45473476B98452f434E72461577d686318",
+"0x52908400098527886E0F7030069857D2E4169ee7",
+"0x5aaEB6053f3e94c9b9a09f33669435E7ef1bEAeD",
+"0x6549F4939460DE12611948B3F82B88C3C8975323",
+"0x66F9664f97f2B50F62d13EA064982F936de76657",
+"0x8617E340b3D01Fa5f11f306f4090fd50E238070D",
+"0x88021160c5C792225E4E5452585947470010289d",
+"0xD1220A0Cf47c7B9BE7a2e6ba89F429762E7B9adB",
+"0xDBF03B407c01E7CD3cBea99509D93F8Dddc8C6FB",
+"0xDe709F2102306220921060314715629080e2FB77",
+"0xFb6916095cA1Df60bb79ce92cE3EA74c37c5d359",
 ]
-rsk_testnet= [
-'0x42712D45473476B98452F434E72461577D686318',
-'0x27B1FdB04752BbC536007a920D24acB045561C26',
-'0x3599689e6292b81b2D85451025146515070129Bb',
-'0x52908400098527886E0F7030069857D2e4169EE7',
-'0x5aAeb6053F3e94c9b9A09F33669435E7EF1BEaEd',
-'0x66f9664F97F2b50f62d13eA064982F936DE76657',
-'0x8617e340b3D01fa5F11f306F4090Fd50e238070d',
-'0xDE709F2102306220921060314715629080e2Fb77',
-'0xFb6916095CA1dF60bb79CE92ce3Ea74C37c5D359',
-'0xd1220a0CF47c7B9Be7A2E6Ba89f429762E7b9adB',
-'0xdbF03B407C01E7cd3cbEa99509D93f8dDDc8C6fB',
+rsk_testnet = [
+"0x27B1FdB04752BbC536007a920D24acB045561C26",
+"0x3599689e6292b81b2D85451025146515070129Bb",
+"0x42712D45473476B98452F434E72461577D686318",
+"0x52908400098527886E0F7030069857D2e4169EE7",
+"0x5aAeb6053F3e94c9b9A09F33669435E7EF1BEaEd",
+"0x6549f4939460dE12611948b3f82b88C3c8975323",
+"0x66f9664F97F2b50f62d13eA064982F936DE76657",
+"0x8617e340b3D01fa5F11f306F4090Fd50e238070d",
+"0x88021160c5C792225E4E5452585947470010289d",
+"0xd1220a0CF47c7B9Be7A2E6Ba89f429762E7b9adB",
+"0xdbF03B407C01E7cd3cbEa99509D93f8dDDc8C6fB",
+"0xDE709F2102306220921060314715629080e2Fb77",
+"0xFb6916095CA1dF60bb79CE92ce3Ea74C37c5D359",
 ]
 test_cases = {30 : rsk_mainnet, 31 : rsk_testnet, 1 : eth_mainnet}
 
@@ -82,19 +101,25 @@ for chainid, cases in test_cases.items():
         assert ( addr == eth_checksum_encode(addr,chainid) )
 ```
 ## Adoption
+
 ### Adoption  Table
+
 | Network      | Chain id | Supports this EIP |
-|--------------|----------|-------------------|
+|-|-|-|
 | RSK Mainnet  | 30       | Yes               |
 | RSK Testnet  | 31       | Yes               |
 
 ### Implementation Table
-| Wallet         | Adopted this EIP | Implementation |
-|----------------|------------------| -------------- |
+
+| Project         | Adopted this EIP | Implementation |
+|-|-|-|
 | MyCrypto       | Yes              | [JavaScript](https://github.com/MyCryptoHQ/MyCrypto/blob/develop/common/utils/formatters.ts#L126) |
 | MyEtherWallet  | Yes              | [JavaScript](https://github.com/MyEtherWallet/MyEtherWallet/blob/73c4a24f8f67c655749ac990c5b62efd92a2b11a/src/helpers/addressUtils.js#L22) |
 | Ledger         | Yes              | [C](https://github.com/LedgerHQ/ledger-app-eth/blob/master/src_common/ethUtils.c#L203) |
 | Trezor         | Yes              | [Python](https://github.com/trezor/trezor-core/blob/270bf732121d004a4cd1ab129adaccf7346ff1db/src/apps/ethereum/get_address.py#L32) and [C](https://github.com/trezor/trezor-crypto/blob/4153e662b60a0d83c1be15150f18483a37e9092c/address.c#L62) |
+| Web3.js           | Yes              | [JavaScript](https://github.com/ethereum/web3.js/blob/aaf26c8806bc9fb60cf6dcb6658104963c6c7fc7/packages/web3-utils/src/Utils.js#L140) |
+| EthereumJS-util   | Yes              | [JavaScript](https://github.com/ethereumjs/ethereumjs-util/pull/204/commits/cdf0b3c996b05ac5b1f758f17ea9f9ed1847c1eb) |
+| ENS address-encoder | Yes | [TypeScript](https://github.com/ensdomains/address-encoder/commit/5bf53b13fa014646ea28c9e5f937361dc9b40590) |
 
 ## Copyright
 

EIPS/eip-1261.md

@@ -295,9 +295,9 @@ One can think of the set of MVTs as identifying a user, and you cannot split the
 
 The assign and revoke functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:
 
-- **Disallow additional memberships after a condition is met** — Sample contract available on Github
-- **Blacklist certain address from receiving MV tokens** — Sample contract available on Github
-- **Disallow additional memberships after a certain time is reached** — Sample contract available on Github
+- **Disallow additional memberships after a condition is met** — Sample contract available on GitHub
+- **Blacklist certain address from receiving MV tokens** — Sample contract available on GitHub
+- **Disallow additional memberships after a certain time is reached** — Sample contract available on GitHub
 - **Charge a fee to user of a transaction** — require payment when calling `assign` and `revoke` so that condition checks from external sources can be made
 
 **ERC-173 Interface**

EIPS/eip-1319.md

@@ -170,7 +170,7 @@ Registries may offer more complex `read` APIs that manage requests for packages
 No existing standard exists for package registries. The package registry currently deployed by EthPM would not comply with the standard since it implements only one of the method signatures described in the specification.
 
 ## Implementation
-A reference implementation of this proposal is in active development at the EthPM organization on Github [here](https://github.com/ethpm/escape-truffle).
+A reference implementation of this proposal is in active development at the EthPM organization on GitHub [here](https://github.com/ethpm/escape-truffle).
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).