links to the yellow paper and wiki #2
Comments
Closed
appyhour770
added a commit
to appyhour770/EIPs
that referenced
this issue
Jan 2, 2018
rpsnoopy
added a commit
to rpsnoopy/EIPs
that referenced
this issue
Oct 29, 2018
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)
gcolvin
pushed a commit
that referenced
this issue
Nov 19, 2018
* Proposed EIP for address and ERC20 transfer rules * Update eip-X.md Updating creation date * Update eip-X.md (#1) * Update eip-X.md * Update eip-X.md * Update eip-X.md Rule -> IRule consistently fix missing links improve abstract * Update eip-X.md typos small improvements adds implementation section
owocki
pushed a commit
to gitcoinco/EIPs
that referenced
this issue
Apr 4, 2019
…-updated EIP getSubscriptionHash and execSubscription have been modified and h…
Closed
weiji-cryptonatty
added a commit
to Base-Labs/EIPs
that referenced
this issue
Nov 25, 2022
eth-bot
pushed a commit
that referenced
this issue
Dec 27, 2022
* added EIP draft for private key encapsulation * minor updates to spec: intake function shall return the Ethereum address of the private key * added test vector #1 * minor formatting * minor edits * added test vector #2 and #3, added signature verification data to #1 * changed signature to against byte values * added test vector generator * renamed file to assigned EIP number * fixed file header * updated default value for salt * fixed offending links etc. * fixed typo Co-authored-by: xinbenlv <zzn@zzn.im> * updated based on review comments * replaced json formatting with none for better rendering * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * revision suggestions taken with gratitudes Co-authored-by: xinbenlv <zzn@zzn.im> * revision suggestions taken with gratitudes Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar Co-authored-by: xinbenlv <zzn@zzn.im> * revision suggestions taken with gratitudes Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar as suggested Co-authored-by: xinbenlv <zzn@zzn.im> * revision suggestions taken with gratitudes Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar as suggested Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar as suggested Co-authored-by: xinbenlv <zzn@zzn.im> * fixed grammar as suggested * fixed based on grammarly.com suggestions * Update EIPS/eip-6051.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> * Update EIPS/eip-6051.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> * Update EIPS/eip-6051.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> * replacing bold fonts with links as suggested * fixed dead links * fixed markdown linter errors Co-authored-by: xinbenlv <zzn@zzn.im> Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
eth-bot
pushed a commit
that referenced
this issue
Apr 11, 2023
…n-eip fix: the first match of the given pattern must be a link
eth-bot
pushed a commit
that referenced
this issue
May 2, 2023
update/add interfaces (updatePlugin, modularAccount), update hooks requirements
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: