status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-16 18:04:31 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into fix-eip-198-typo

Browse Source
This commit is contained in:
Greg Colvin 2018-09-25 12:17:29 -06:00 committed by GitHub
commit 1b092270d4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 48 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
EIPS/eip-1066.md
View File

@ -105,7 +105,7 @@ explanatory and layout reasons.
Unspecified codes are _not_ free for arbitrary use, but rather open for further specification.
#### Generic
#### `0x0*` Generic
General codes. These double as bare "reasons", since `0x01 == 1`.
@ -128,7 +128,7 @@ General codes. These double as bare "reasons", since `0x01 == 1`.
| `0x0E` | |
| `0x0F` | Meta or Info Only |
#### Permission
#### `0x1*` Permission
Related to permisson, authorization, approval, and so on.
@ -151,7 +151,7 @@ Related to permisson, authorization, approval, and so on.
| `0x1E` | |
| `0x1F` | Permission Meta or Info |
#### Find, Match, &c
#### `0x2*` Find, Match, &c
This range is broadly intended for finding and matching.
Data lookups and order matching are two common use cases.
@ -175,7 +175,7 @@ Data lookups and order matching are two common use cases.
| `0x2E` | |
| `0x2F` | Matching Meta or Info |
#### Negotiation, Terms, and Offers
#### `0x3*` Negotiation, Terms, and Offers
Negotiation, and very broadly the flow of such transactions.
Note that "other party" may be more than one actor (not necessarily the sender).
@ -199,7 +199,7 @@ Note that "other party" may be more than one actor (not necessarily the sender).
| `0x3E` | |
| `0x3F` | Negotiation Meta or Info |
#### Availability
#### `0x4*` Availability
Service or action availability.
@ -222,27 +222,27 @@ Service or action availability.
| `0x4E` | |
| `0x4F` | Availability Meta or Info |
#### `0x5_` TBD
#### `0x5*` TBD
Currently unspecified
#### `0x6_` TBD
#### `0x6*` TBD
Currently unspecified
#### `0x7_` TBD
#### `0x7*` TBD
Currently unspecified
#### `0x8_` TBD
#### `0x8*` TBD
Currently unspecified
#### `0x9_` TBD
#### `0x9*` TBD
Currently unspecified
#### Application-Specific Codes
#### `0xA*` Application-Specific Codes
Contracts may have special states that they need to signal.
This proposal only outlines the broadest meanings, but implementers may have very
@ -267,19 +267,19 @@ specific meanings for each, as long as they are coherent with the broader defini
| `0xAE` | |
| `0xAF` | App-Specific Meta or Info |
#### `0xB_` TBD
#### `0xB*` TBD
Currently unspecified
#### `0xC_` TBD
#### `0xC*` TBD
Currently unspecified
#### `0xD_` TBD
#### `0xD*` TBD
Currently unspecified
#### Cryptography and Authentication
#### `0xE*` Cryptography and Authentication
Actions around signatures, cryptography, signing, and application-level authentication.
@ -307,7 +307,7 @@ or process used.
#### `0xF0` Off-Chain
For off-chain actions. Much like th `0x0_: Generic` range, `0xF_` is very general,
For off-chain actions. Much like th `0x0_: Generic` range, `0xF*` is very general,
and does little to modify the reason.
Among other things, the meta code `0xFF` may be used to describe what the off-chain process is.
@ -489,7 +489,7 @@ most forwards-compatible method of transmission is as the first value of a multi
Familiarity is also a motivating factor. A consistent position and encoding together
follow the principle of least surprise. It is both viewable as a "header" in the HTTP analogy,
or like the "tag" in BEAM tagged tupples.
or like the "tag" in BEAM tagged tuples.
### Human Readable
@ -500,7 +500,13 @@ Cognitive load is lowered by organizing the table into categories and reasons.
While this repository includes helper enums, we have found working directly in
the hex values to be quite natural. ESC `0x10` is just as comfortable as HTTP 401, for example.
### Extensiblilty
#### Localizations
One commonly requested application of this spec is human-readable translations
of codes. This has been moved to its own proposal: [ERC-1444](https://github.com/ethereum/EIPs/pull/1444/),
primarily due to a desire to keep both specs focused.
### Extensibility
The `0xA` category is reserved for application-specific statuses.
In the case that 256 codes become insufficient, `bytes1` may be embedded in larger byte arrays.
@ -526,7 +532,7 @@ but becomes very natural after a couple hours of use.
#### Short Forms
Generic is `0x0_`, general codes are consistent with their integer representations
Generic is `0x0*`, general codes are consistent with their integer representations
```solidity
hex"1" == hex"01" == 1 // with casting

12
EIPS/eip-712.md
View File

@ -375,19 +375,19 @@ function hashStruct(Mail memory mail) pure returns (bytes32 hash) {
assembly {
// Back up select memory
let temp1 := mload(sub(order, 32))
let temp2 := mload(add(order, 128))
let temp1 := mload(sub(mail, 32))
let temp2 := mload(add(mail, 128))
// Write typeHash and sub-hashes
mstore(sub(mail, 32), typeHash)
mstore(add(order, 64), contentsHash)
mstore(add(mail, 64), contentsHash)
// Compute hash
hash := keccak256(sub(order, 32), 128)
hash := keccak256(sub(mail, 32), 128)
// Restore memory
mstore(sub(order, 32), temp1)
mstore(add(order, 64), temp2)
mstore(sub(mail, 32), temp1)
mstore(add(mail, 64), temp2)
}
}
```

28
EIPS/eip-725.md
View File

@ -10,14 +10,14 @@ created: 2017-10-02
---
## Simple Summary
Proxy contract for key management and execution, to establish a Blockchain identity.
A proxy contract for key management and execution, to establish a Blockchain identity.
## Abstract
The following describes standard functions for a unique identity for humans, groups, objects and machines.
This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested ([#ERC735](https://github.com/ethereum/EIPs/issues/735)), as well as a proxy function to act directly on the blockchain.
This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self-attested ([#ERC735](https://github.com/ethereum/EIPs/issues/735)), as well as a proxy function, to act directly on the blockchain.
## Motivation
This standardised identity interface will allow Dapps, smart contracts and thirdparties to check the validity of a person, organisation, object or machine through 2 steps as described in the function XXX. Trust is here transfered to the issuers of claims.
This standardized identity interface will allow Dapps, smart contracts and third parties to check the validity of a person, organization, object or machine through 2 steps as described in the function XXX. Trust is here transferred to the issuers of claims.
The most important functions to verify an identity are: `XXX`
@ -26,7 +26,7 @@ The most important functions to manage an identity are: `XXX`
## Definitions
- `keys`: Keys are public keys from either external accounts, or contract addresses.
- `keys`: Keys are public keys from either external accounts, or contracts' addresses.
- `claim issuer`: is another smart contract or external account, which issues claims about this identity. The claim issuer can be an identity contract itself.
- `claim`: For details about claims see [#ERC735](https://github.com/ethereum/EIPs/issues/735)
@ -64,7 +64,7 @@ function getKey(bytes32 _key) constant returns(uint256[] purposes, uint256 keyTy
#### keyHasPurpose
Returns the `TRUE` if a key has is present and has the given purpose. If key is not present it returns `FALSE`.
Returns the `TRUE` if a key has is present and has the given purpose. If the key is not present it returns `FALSE`.
``` js
function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);
@ -82,11 +82,11 @@ function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys);
#### addKey
Adds a `_key` to the identity. The `_purpose` specifies the purpose of key. Initially we propose four purposes:
Adds a `_key` to the identity. The `_purpose` specifies the purpose of the key. Initially, we propose four purposes:
- `1`: MANAGEMENT keys, which can manage the identity
- `2`: ACTION keys, which perform actions in this identities name (signing, logins, transactions, etc.)
- `3`: CLAIM signer keys, used to sign claims on other identities which need to be revokable.
- `3`: CLAIM signer keys, used to sign claims on other identities which need to be revocable.
- `4`: ENCRYPTION keys, used to encrypt data e.g. hold in claims.
MUST only be done by keys of purpose `1`, or the identity itself. If its the identity itself, the approval process will determine its approval.
@ -121,9 +121,9 @@ function removeKey(bytes32 _key, uint256 _purpose) returns (bool success)
Executes an action on other contracts, or itself, or a transfer of ether.
SHOULD require `approve` to be called with one or more keys of purpose `1` or `2` to approve this execution.
Execute COULD be used as the only accessors for `addKey`, `removeKey` and `replaceKey` and `removeClaim`.
Execute COULD be used as the only accessor for `addKey`, `removeKey` and `replaceKey` and `removeClaim`.
**Returns `executionId`:** SHOULD be send to the `approve` function, to approve or reject this execution.
**Returns `executionId`:** SHOULD be sent to the `approve` function, to approve or reject this execution.
**Triggers Event:** [ExecutionRequested](#executionrequested)
**Triggers on direct execution Event:** [Executed](#executed)
@ -136,8 +136,8 @@ function execute(address _to, uint256 _value, bytes _data) returns (uint256 exec
#### approve
Approves an execution or claim addition.
This SHOULD require `n` of `m` approvals of keys purpose `1`, if the `_to` of the execution is the identity contract itself, to successfull approve an execution.
And COULD require `n` of `m` approvals of keys purpose `2`, if the `_to` of the execution is another contract, to successfull approve an execution.
This SHOULD require `n` of `m` approvals of keys purpose `1`, if the `_to` of the execution is the identity contract itself, to successfully approve an execution.
And COULD require `n` of `m` approvals of keys purpose `2`, if the `_to` of the execution is another contract, to successfully approve an execution.
**Triggers Event:** [Approved](#approved)
**Triggers on successfull execution Event:** [Executed](#executed)
@ -159,7 +159,7 @@ Requires: [ERC 735](https://github.com/ethereum/EIPs/issues/735)
#### addClaim
This SHOULD create a pending claim, which SHOULD to be approved or rejected by `n` of `m` `approve` calls from keys of purpose `1`.
This SHOULD create a pending claim, which SHOULD be approved or rejected by `n` of `m` `approve` calls from keys of purpose `1`.
Only Events:
**Triggers if the claim is new Event and approval process exists:** [ClaimRequested](#claimrequested)
@ -241,9 +241,9 @@ MUST be triggered when `approve` was called and the claim was successfully added
## Rationale
This specification was chosen to allow most flexibility and experimention around identity. By having each identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases.
This specification was chosen to allow most flexibility and experimentation around identity. By having each identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases.
The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While [#ERC780](https://github.com/ethereum/EIPs/issues/780) uses a standardised registry to assign claims to addresses.
The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While [#ERC780](https://github.com/ethereum/EIPs/issues/780) uses a standardized registry to assign claims to addresses.
Both systems could work in conjunction and should be explored.
While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored.

7
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 susceptable 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 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 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.
### Specification
@ -216,8 +216,7 @@ function getChallengeNumber() public view returns (bytes32);
#### getMiningDifficulty
The number of digits that the digest of the PoW solution requires which typically auto adjusts during reward generation.Return the current reward amount. Depending on the algorithm, typically rewards are divided every reward era as tokens are mined to provide scarcity.
The number of digits that the digest of the PoW solution requires which typically auto adjusts during reward generation.
``` js
function getMiningDifficulty() public view returns (uint)
@ -246,7 +245,7 @@ Once the nonce and hash1 are found, these are used to call the mint() function o
### Rationale
A keccak256 algoritm 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.
A 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 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.