Update EIP-918: Move from Stagnant to Draft

EIPS/eip-918.md

@@ -1,27 +1,21 @@
 ---
 eip: 918
 title: Mineable Token Standard
+description: A specification for standardized Mineable Tokens that uses a Proof of Work algorithm for distribution.
 author: Jay Logelin (@jlogelin), Infernal_toast <[email protected]>, Michael Seiler <[email protected]>, Brandon Grill <[email protected]>
-type: Standards Track
-category: ERC
 status: Last Call
+type: Standards Track
+category ERC
 created: 2018-03-07
 ---
-
-### Simple Summary
-
-A specification for a standardized Mineable Token that uses a Proof of Work algorithm for distribution. 
-
-### Abstract
 
+## Abstract
 This specification describes a method for initially locking tokens within a token contract and slowly dispensing them with a mint() function which acts like a faucet. This mint() function uses a Proof of Work algorithm in order to minimize gas fees and control the distribution rate. Additionally, standardization of mineable tokens will give rise to standardized CPU and GPU token mining software, token mining pools and other external tools in the token mining ecosystem.
 
-### Motivation
-
+## Motivation
 Token distribution via the ICO model and its derivatives is susceptible to illicit behavior by human actors. Furthermore, new token projects are centralized because a single entity must handle and control all of the initial coins and all of the raised ICO money.  By distributing tokens via an 'Initial Mining Offering' (or IMO), the ownership of the token contract no longer belongs with the deployer at all and the deployer is 'just another user.' As a result, investor risk exposure utilizing a mined token distribution model is significantly diminished. This standard is intended to be standalone, allowing maximum interoperability with ERC20, ERC721, and others.
 
-### Specification
-
+## Specification
 #### Interface
 The general behavioral specification includes a primary function that defines the token minting operation, an optional merged minting operation for issuing multiple tokens, getters for challenge number, mining difficulty, mining target and current reward, and finally a Mint event, to be emitted upon successful solution validation and token issuance. At a minimum, contracts must adhere to this interface (save the optional merge operation). It is recommended that contracts interface with the more behaviorally defined Abstract Contract described below, in order to leverage a more defined construct, allowing for easier external implementations via overridden phased functions. (see 'Abstract Contract' below)
 
@@ -415,16 +409,14 @@ Mineable Token Metadata JSON schema definition:
 }
 ```
 
-### Rationale
-
+## Rationale
 The solidity keccak256 algorithm does not have to be used, but it is recommended since it is a cost effective one-way algorithm to perform in the EVM and simple to perform in solidity. The nonce is the solution that miners try to find and so it is part of the hashing algorithm. A challengeNumber is also part of the hash so that future blocks cannot be mined since it acts like a random piece of data that is not revealed until a mining round starts. The msg.sender address is part of the hash so that a nonce solution is valid only for a particular Ethereum account and so the solution is not susceptible to man-in-the-middle attacks. This also allows pools to operate without being easily cheated by the miners since pools can force miners to mine using the pool's address in the hash algorithm.  
 
 The economics of transferring electricity and hardware into mined token assets offers a flourishing community of decentralized miners the option to be involved in the Ethereum token economy directly. By voting with hash power, an economically pegged asset to real-world resources, miners are incentivized to participate in early token trade to revamp initial costs, providing a bootstrapped stimulus mechanism between miners and early investors.
 
 One community concern for mined tokens has been around energy use without a function for securing a network.  Although token mining does not secure a network, it serves the function of securing a community from corruption as it offers an alternative to centralized ICOs. Furthermore, an initial mining offering may last as little as a week, a day, or an hour at which point all of the tokens would have been minted.
 
-
-### Backwards Compatibility
+## Backwards Compatibility
 Earlier versions of this standard incorporated a redundant 'challenge_digest' parameter on the mint() function that hash-encoded the packed variables challengeNumber, msg.sender and nonce. It was decided that this could be removed from the standard to help minimize processing and thereby gas usage during mint operations. However, in the name of interoperability with existing mining programs and pool software the following contract can be added to the inheritance tree:
 
 ``` solidity
@@ -449,31 +441,48 @@ contract ERC918BackwardsCompatible is AbstractERC918 {
 }
 ```
 
-### 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.)
+## Test Cases
 
+See Reference Implementation
 
-### Implementation
+## Reference Implementation
 
-Simple Example:
+#### Core Reference Implmenation, 0xBitcoin:
 https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/SimpleERC918.sol
 
-Complex Examples:
+#### 0xBitcoin Token Contract: 
+https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31
+
+Other Examples:
 
 https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xdogeExample.sol
 https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xdogeExample2.sol
 https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xBitcoinBase.sol
 
-0xBitcoin Token Contract: 
-https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31
+#### Miner Implementations:
 
 MVI OpenCL Token Miner 
 https://github.com/mining-visualizer/MVis-tokenminer/releases
 
 PoWAdv Token Contract:
 https://etherscan.io/address/0x1a136ae98b49b92841562b6574d1f3f5b0044e4c
 
+## Security Considerations
+This specification suggests using the keccak256/sha3 algorithm proof of work mechanism for its security hardness, explicitly certified by the National Institute of Standards and Technology (NIST) via FIPS 202. (https://csrc.nist.gov/publications/detail/fips/202/final).
 
-### Copyright
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+Additionally, guards should be added to proof of work verification that explicitely arrests execution of the mint function upon failure. For example:
+
+``` solidity
+	function mint(uint256 nonce, bytes32 challenge_digest) public returns (bool success) {
+        // perform the hash function validation
+        digest = bytes32(keccak256(nonce, challenge_digest));
+        require(digest >= bytes32(difficulty));
 
+        ...
+    }
+
+```
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).