Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

links to the yellow paper and wiki #2

Closed
wanderer opened this issue Oct 26, 2015 · 0 comments
Closed

links to the yellow paper and wiki #2

wanderer opened this issue Oct 26, 2015 · 0 comments

Comments

@wanderer
Copy link
Member

No description provided.

appyhour770 added a commit to appyhour770/EIPs that referenced this issue Jan 2, 2018
nicksavers pushed a commit that referenced this issue Mar 9, 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…
gcolvin added a commit that referenced this issue Feb 19, 2020
SamWilsn referenced this issue in SamWilsn/EIPs Jul 18, 2022
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 <[email protected]>

* updated based on review comments

* replaced json formatting with none for better rendering

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* revision suggestions taken with gratitudes

Co-authored-by: xinbenlv <[email protected]>

* revision suggestions taken with gratitudes

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar

Co-authored-by: xinbenlv <[email protected]>

* revision suggestions taken with gratitudes

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar as suggested

Co-authored-by: xinbenlv <[email protected]>

* revision suggestions taken with gratitudes

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar as suggested

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar as suggested

Co-authored-by: xinbenlv <[email protected]>

* fixed grammar as suggested

* fixed based on grammarly.com suggestions

* Update EIPS/eip-6051.md

Co-authored-by: Pandapip1 <[email protected]>

* Update EIPS/eip-6051.md

Co-authored-by: Pandapip1 <[email protected]>

* Update EIPS/eip-6051.md

Co-authored-by: Pandapip1 <[email protected]>

* replacing bold fonts with links as suggested

* fixed dead links

* fixed markdown linter errors

Co-authored-by: xinbenlv <[email protected]>
Co-authored-by: Pandapip1 <[email protected]>
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
potuz referenced this issue in potuz/EIPs Jun 29, 2024
jacobkaufmann pushed a commit to jacobkaufmann/EIPs that referenced this issue Oct 9, 2024
Update main FOCIL functions: Agg, Eval and Valid
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant