Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revised to fullfill EIP typical scope
ethereum#1) SLASHED #### MIN_TARGET Returns the minimum possible target that the mineable contract will provide as part of the proof of work algorithm. ```solidity function MIN_TARGET() external public returns (uint256) ``` #### MAX_TARGET Returns the maximum possible target that the mineable contract will provide as part of the proof of work algorithm. ```solidity function MAX_TARGET() external public returns (uint256) ``` # MOTIVATION: These are not (i) general needed variables (THEY APPLY TO THE BITCOIN DIFFICULTY ADJUSTEMENT MODEL ONLY); (ii) the mining SW (that need to interface the EIP918) do not have any advantage or needing to know those values, because it do not implement any strategy. As a consequence they DO NOT find place in a MANDATORY description for the standard. Nobody prevent from having those values in a public variables, but here we use the lawyer paradigm, where any added constraint slash out classes of applications, i.e. if you allow to have any MAX_TARGET mandatory variable, any mining facility using algorithms that do not use this approach are slashed out from the standard. ADVICE: Move them in the example section (neither in recommended). # 2) CHOOSE ONE FROM TWO #### blocksPerReadjustment Returns the number of block rewards per difficulty readjustment. ```solidity function blocksPerReadjustment() external returns (uint); ``` #### adjustmentInterval Returns the target interval, in seconds, between two successive difficulty adjustments. ```solidity function adjustmentInterval () external public returns (uint) ``` **NOTES**: in a common implementation, while `difficulty` varies when computational power is added/subtracted to the network, the `adjustmentInterval` is fixed at deploy time. # MOTIVATION: THE TWO METHODS are the same thing, expressed in two different metrics. You can pass from one to the other simply using a conversion, like inchs and cm.. We do not want to ask for a MANDATORY presence of both cm and inches. We have to choose one of them. My proposal is to use blocksPerReadjustment because it is more general, being able to include models where the generation of the new block is not fixed in the time, but comes out different situation (think to a possible model where the next block is generated if and only when some conditions are met. For instance if and only some token are burnt somewhere. It is an example only!). ethereum#3)ADDED PARENTHESIS AT LINE 181, after the word challengeNumber. ethereum#2)SLASHED ### Mineable Token Metadata (Optional) In order to provide for richer and potentially mutable metadata for a particular Mineable Token, it is more viable to offer an off-chain reference to said data. This requires the implementation of a single interface method 'metadataURI()' that returns a JSON string encoded with the string fields symbol, name, description, website, image, and type. Solidity interface for Mineable Token Metadata: ``` solidity /** * @title ERC-918 Mineable Token Standard, optional metadata extension * @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-918.md * */ interface ERC918Metadata is AbstractERC918 { /** * @notice A distinct Uniform Resource Identifier (URI) for a mineable asset. */ function metadataURI() external view returns (string); } ``` Mineable Token Metadata JSON schema definition: ``` solidity { "title": "Mineable Token Metadata", "type": "object", "properties": { "symbol": { "type": "string", "description": "Identifies the Mineable Token's symbol", }, "name": { "type": "string", "description": "Identifies the Mineable Token's name", }, "description": { "type": "string", "description": "Identifies the Mineable Token's long description", }, "website": { "type": "string", "description": "Identifies the Mineable Token's homepage URI", }, "image": { "type": "string", "description": "Identifies the Mineable Token's image URI", }, "type": { "type": "string", "description": "Identifies the Mineable Token's hash algorithm ( ie.keccak256 ) used to encode the solution", } } } ``` #MOTIVATION This description is a well known proposed ERC20 improvement. This standard (EIP918) is referred to the mining properties of a token only, being referred to the other eventual standards for interface related to token representation and management (ERC20, ERC721 and so on). # FLUSHED SOMEWHERE OR SLASHED ### 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. MOTIVATION: 1) GENERAL: THE RATIONALE OF THE STANDARD CANNOT BE CONTAINED IN THE RECCOMENDATION 2) FURTHERMORE: the solidity keccak256 reccomendation can stay here properly contestualized (FLUSHED) 3) “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.” -> SLASHED BECAUSE the rationale of a standard is not something that recommend to use POW, but something that resolves the needing to rationalize and standardize the interfaces of different possible implementations. Full STOP. This come out from THE FACT that the community USES pow already. We are not worried about concerns of the community, this is a standard, no opinion can be written here, but technical prescription. The maximum we can do is to represent “some” motivations of the community in the preamble before the standard declination. WE DO NOT HAVE TO CONVINCE PEOPLE USING A STANDARD; WE GIVE MANDATORY PRESCRIPTION ONLY. 4) “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.” -> SLASHED BECAUSE IT SIMPLY repeats the same concepts described elsewhere (MITM attack and anticipated mining in Recommendation)
- Loading branch information
