status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into fix_create2

This commit is contained in:
Martin Holst Swende 2018-09-28 16:22:18 +02:00 committed by GitHub
parent 0e1a240f04 2fc13ead12
commit 5d83a9d732
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
EIPS/eip-918.md
View File

@ -18,7 +18,7 @@ This specification describes a method for initially locking tokens within a toke
### Motivation
Token distribution via the ICO model and it's 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.
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
@ -97,7 +97,7 @@ uint public epochCount;
#### mint
Returns a flag indicating a successful hash digest verification, and reward allocation to msg.sender. In order to prevent MiTM attacks, it is recommended that the digest include a recent ethereum block hash and msg.sender's address. Once verified, the mint function calculates and delivers a mining reward to the sender and performs internal accounting operations on the contract's supply.
Returns a flag indicating a successful hash digest verification, and reward allocation to msg.sender. In order to prevent MiTM attacks, it is recommended that the digest include a recent Ethereum block hash and msg.sender's address. Once verified, the mint function calculates and delivers a mining reward to the sender and performs internal accounting operations on the contract's supply.
The mint operation exists as a public function that invokes 4 separate phases, represented as functions hash, \_reward, \_newEpoch, and \_adjustDifficulty. In order to create the most flexible implementation while adhering to a necessary contract protocol, it is recommended that token implementors override the internal methods, allowing the base contract to handle their execution via mint.
@ -288,7 +288,7 @@ contract ERC918Merged is AbstractERC918 {
```
### Delegated Minting Extension (Optional)
In order to facilitate a third party minting submission paradigm, such as the case of miners submitting solutions to a pool operator and/or system, a delegated minting extension can be used to allow pool accounts submit solutions on the behalf of a user, so the miner can avoid directly paying Ethereum transaction costs. This is performed by an offchain mining account packaging and signing a standardized mint solution packet and sending it to a pool or 3rd party to be submitted.
In order to facilitate a third party minting submission paradigm, such as the case of miners submitting solutions to a pool operator and/or system, a delegated minting extension can be used to allow pool accounts submit solutions on the behalf of a user, so the miner can avoid directly paying Ethereum transaction costs. This is performed by an off chain mining account packaging and signing a standardized mint solution packet and sending it to a pool or 3rd party to be submitted.
The ERC918 Mineable Mint Packet Metadata should be prepared using following schema:
``` solidity
@ -306,23 +306,23 @@ The ERC918 Mineable Mint Packet Metadata should be prepared using following sche
},
"signature": {
"type": "string",
"description": "The signed hash of tightly packed variables sha3('delegatedMintHashing(address,uint256)')+nonce+origin_account",
"description": "The signed hash of tightly packed variables sha3('delegatedMintHashing(uint256,address)')+nonce+origin_account",
}
}
}
```
The preparation of a mineable mint packet on a javascript client would appear as follows:
The preparation of a mineable mint packet on a JavaScript client would appear as follows:
``` solidity
const ethUtil = require("ethereumjs-util")
function prepareDelegatedMintTxn(nonce, address, privateKey) {
var functionSig = web3.sha3("delegatedMintHashing(address,uint256)").substring(0,10)
var functionSig = web3.sha3("delegatedMintHashing(uint256,address)").substring(0,10)
var hashOf = "0x" + bytes4ToHex(functionSig) + uint256ToHex(nonce) +addressToHex(accounts[1])
var data = ethUtil.sha3(hashOf)
var signature = ethUtil.ecsign(data, new Buffer(privateKey, 'hex'))
var sig = ethUtil.toRpcSig(signature.v, signature.r, signature.s)
// prepare the mint packet
// prepare the mint packet
var packet = {}
packet.nonce = nonce;
packet.origin = address;
@ -332,7 +332,7 @@ function prepareDelegatedMintTxn(nonce, address, privateKey) {
/* todo: send mineableMintPacket to submitter */
}
```
Once the packet is prepared and formatted it can then be routed to a third party that will submit the transaction to the contract's deletedMint() function, thereby paying for the transaction gas and receiving the resulting tokens. The pool/third party must then manually payback the minted tokens minus fees to the original minter.
Once the packet is prepared and formatted it can then be routed to a third party that will submit the transaction to the contract's delegatedMint() function, thereby paying for the transaction gas and receiving the resulting tokens. The pool/third party must then manually payback the minted tokens minus fees to the original minter.
The following code sample exemplifies third party packet relaying:
``` solidity
@ -364,7 +364,7 @@ contract ERC918DelegatedMint is AbstractERC918 {
* @param _origin the original minter
*/
function delegatedMintHashing(uint256 _nonce, address _origin) internal pure returns (bytes32) {
/* "0xb548f23d": delegatedMintHashing(address,uint256) */
/* "0xb548f23d": delegatedMintHashing(uint256,address) */
return keccak256( abi.encodePacked( bytes4(0xb548f23d), _nonce, _origin) );
}
}
@ -424,9 +424,9 @@ Mineable Token Metadata JSON schema definition:
### 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 algo.
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 hashpower, 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.
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.
@ -483,3 +483,4 @@ https://etherscan.io/address/0x1a136ae98b49b92841562b6574d1f3f5b0044e4c
### Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).