Spelling, Grammar, Initial Structure #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wanderer
added a commit
that referenced
this pull request
Oct 27, 2015
Spelling, Grammar, Initial Structure
rpsnoopy
added a commit
to rpsnoopy/EIPs
that referenced
this pull request
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)
SamWilsn
pushed a commit
to SamWilsn/EIPs
that referenced
this pull request
Jul 18, 2022
Missing sections
weiji-cryptonatty
added a commit
to Base-Labs/EIPs
that referenced
this pull request
Nov 25, 2022
eth-bot
pushed a commit
that referenced
this pull request
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 pull request
Apr 11, 2023
…n-eip feat: fix linting errors
RaphaelHardFork
pushed a commit
to RaphaelHardFork/EIPs
that referenced
this pull request
Jan 30, 2024
* Updated 5164 to Last Call * Bumped last call deadline by a few more days
bumblefudge
pushed a commit
to bumblefudge/EIPs
that referenced
this pull request
Feb 16, 2024
To add bip122.md
just-a-node
pushed a commit
to connext/EIPs
that referenced
this pull request
Feb 17, 2024
* Updated 5164 to Last Call * Bumped last call deadline by a few more days
g11tech
referenced
this pull request
in g11tech/EIPs
Apr 12, 2024
…add eip 158 handling strategy (#3) * Update the eip to store in ring buffer instead of serial storage and add eip 158 handling strategy * address feedback * typo * more typos * fix a reference * further cleanup * apply feedback * apply feedback * fix typo
Gedoxa
approved these changes
Apr 16, 2024
| @@ -3,24 +3,30 @@ | |||
| Title: EIP Purpose and Guidelines | |||
| Status: Draft | |||
| Type: Meta | |||
| Created: 2011-08-19 | |||
jacobkaufmann
pushed a commit
to jacobkaufmann/EIPs
that referenced
this pull request
Oct 9, 2024
Update timeline section
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.