Make even with master

EIPS/eip-1077.md

@@ -35,7 +35,7 @@ Standardizing a common format for them, as well as a way in which the user allow
 Executes `_execData` with current `lastNonce()` and pays `msg.sender` the gas used in specified `_gasToken`.
 
 ```solidity
-function executeGasRelay(bytes calldata _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, bytes calldata _signature) external;	
+function executeGasRelay(bytes calldata _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer, bytes calldata _signature) external;	
 ```
 
 ### executeGasRelayMsg
@@ -71,11 +71,11 @@ The signed message require the following fields:
 * Gas Price: The gas price (paid in the selected token);
 * Gas Limit: The gas reserved to the relayed execution;
 * Gas Token: A token in which the gas will be paid (leave 0 for ether);
-* Gas Relayer: the authorized relayer for this message.
+* Gas Relayer: the beneficiary of gas refund for this call (leave 0 for `block.coinbase`) .
 
 #### Signing the message
 
-The message **MUST** be signed as [EIP-191] standard, and the called contract m**MUST**ust also implement [EIP-1271] which must validate the signed messages.
+The message **MUST** be signed as [EIP-191] standard, and the called contract **MUST** also implement [EIP-1271] which must validate the signed messages.
 
 Messages **MUST** be signed by the owner of the account contract executing. If the owner is a contract, it must implement [EIP-1271] interface and forward validation to it. 
 
@@ -159,7 +159,11 @@ Using a self call to evaluate `_execBytes` is not mandatory, depending on the ac
 
 The implementing contract must keep track of the gas spent. One way to do it is to first call `gasLeft()` at the beginning of the function and then after executing the desired action and compare the difference.
 
-The contract then will make a token transfer (or ether, if `tokenAddress` is nil) in the value of `gasSpent * gasPrice` to the `msg.sender`, that is the account that deployed the message. If there are not enough funds, or if the total surpasses `gasLimit` then the transaction MUST revert.
+The contract then will make a token transfer (or ether, if `tokenAddress` is nil) in the value of `gasSpent * gasPrice` to the `_gasRelayer`, that is the account that deployed the message.
+
+If `_gasRelayer` is zero, then the funds **MUST** go to `block.coinbase`.
+
+If there are not enough funds, or if the total surpasses `gasLimit` then the transaction **MUST** revert.
 
 If the executed transaction fails internally, nonces should still be updated and gas needs to be paid.
 
@@ -187,6 +191,8 @@ TBD
 
 One initial implementation of such a contract can be found at [Status.im account-contracts repository](https://github.com/status-im/account-contracts/blob/develop/contracts/account/AccountGasAbstract.sol)
 
+Other version is implemented as Gnosis Safe variant in: http://github.com/status-im/safe-contracts
+
 ### Similar implementations
 
 The idea of using signed messages as executable intent has been around for a while and many other projects are taking similar approaches, which makes it a great candidate for a standard that guarantees interoperability:
@@ -210,6 +216,7 @@ Deployers of transactions (relayers) should be able to call untrusted contracts,
 Is also interest of relayers to maintaining a private reputation of contracts they interact with, as well as keep track of which tokens and for which `gasPrice` they’re willing to deploy transactions.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
 ## References

EIPS/eip-1102.md

@@ -32,8 +32,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `eth_requestAccounts`. Calling this method may trigger a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts or is rejected with an `Error` if accounts are not available.
 
-```js
-ethereum.send('eth_requestAccounts'): Promise<string>
+```typescript
+ethereum.send('eth_requestAccounts'): Promise<Array<string>>
 ```
 
 #### Provider#enable (DEPRECATED)
@@ -42,7 +42,7 @@ ethereum.send('eth_requestAccounts'): Promise<string>
 
 Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `ethereum.enable()`. Calling this method triggers a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts if the user approves access or rejected with an `Error` if the user rejects access.
 
-```js
+```typescript
 ethereum.enable(): Promise<any>
 ```
 

EIPS/eip-1202.md

@@ -38,57 +38,16 @@ Voting is one of the earliest example of EVM programming, and also a key to DAO/
 
 ## Specifications
 
-### Simple Version
-The simple version of specification makes the assumption that each smart contract voting standard is: *Single Issue*, *Single Selection* and *Single Outcome*
-
 ```solidity
-pragma solidity ^0.4.22;
-
-
-/**
- * - Single issue
- * - Single selection
- *
- * Discussion:
- *   1. Each address has a weight determined by other input decided by the actual implementation
- *      which is suggested to be set upon the initialization
- *   2. Is there certain naming convention to follow?
- */
-interface ERC1202 {
-
-    // Vote with an option. The caller needs to handle success or not
-    function vote(uint option) external returns (bool success);
-    function setStatus(bool isOpen) external returns (bool success);
-
-    function issueDescription() external view returns (string desc);
-    function availableOptions() external view returns (uint[] options);
-    function optionDescription(uint option) external view returns (string desc);
-    function ballotOf(address addr) external view returns (uint option);
-    function weightOf(address addr) external view returns (uint weight);
-    function getStatus() external view returns (bool isOpen);
-    function weightedVoteCountsOf(uint option) external view returns (uint count);
-    function winningOption() external view returns (uint option);
-
-    event OnVote(address indexed _from, uint _value);
-    event OnStatusChange(bool newIsOpen);
-}
-```
-
-### Advanced Version
-```solidity
-pragma solidity ^0.4.22;
+pragma solidity ^0.5.8;
 
 
 /**
  * - Multiple issue
  * - Multiple selection
  * - Ordered multiple result
- * Discussion:
- *   1. Each address has a weight determined by other input decided by the actual implementation
- *      which is suggested to be set upon the initialization
- *   2. Is there certain naming convention to follow?
- */
-contract AdvancedERC1202 {
+ **/
+contract ERC1202 {
 
     // Vote with an option. The caller needs to handle success or not
     function vote(uint issueId, uint option) public returns (bool success);
@@ -137,30 +96,22 @@ There is no backward compatibility issue we are aware of.
  - [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/advanced-version/AdvancedTokenVote1202.sol)
  - [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0xfd8b3be5f9db4662d1c9269f948345b46e37fd26#code)
 
+## Security Considerations
 
-## Summary of Discussions
-
-### Early Feedback Questions (2018-07-08)
-Here are a few early questions I'd like to ask people here.
-1. Have we had any duplicated EIPs that I overlooked. If not, have anyone attempted to do so, and why it did not continue to exist? 
-**Answer**: We concluded there is no duplicated efforts working on creating a voting standard.
-
-2. Should each issue have its own smart contract address (like individual item on [EIP-721](https://eips.ethereum.org/EIPS/eip-721)) or should it support multiple items in [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155), or should it support multi-class voting in [EIP-1178](https://eips.ethereum.org/EIPS/eip-1178), [EIP-1203](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1203.md) (e.g. certain issue can override another issue) 
-**Answer**: We will provide examples of both and seek comments.
-
-3. Should the voting support proxy(e.g [EIP-897](https://eips.ethereum.org/EIPS/eip-897), [EIP-1167](https://eips.ethereum.org/EIPS/eip-1167)) and migration? What are potential security concerns
-**Answer**: It shall not be determined by this ERC.
-
-4. Should it be proposed in a single phase standard or multiple separate into multiple phase, with earlier phase supporting easiest and simplest interface, and later phase supporting more advanced interfaces? (I intuitively believe it will be the latter, but not sure if it might be possible to do it all-at once.)
-**Answer**: It will unavoidably require upgrade in the future, but supporting multiple issue multiple options will be good enough so far.
-
-1. Should it support or optionally support [EIP-165](https://eips.ethereum.org/EIPS/eip-165)? For public voting, support EIP-165 make it easier to discover, but for secret voting people might not want to disclose a voting for certain issue even exist.
-**Answer**: It shall not be determined by this ERC. 
-
-### Second Feedback Questions 2018-07-19
-1. Is it technically possible to achieve anonymous voting on current Ethereum/EVM setup, is it possible that people either hide their identity, or hide what selection they made in a vote given that for a smart contract the public states are visible from block history directly, and internal private state can be replied in any fullnode?
-
-2. number byte length: for simplicity we are using `uint` anywhere undecided. We need to decided what number byte length should we use for `weights` and `options`.
+EIP-1202 is a voting standard. We expect the voting standard to be used in connection with other contracts such as token distributions, conducting actions in consensus or on behalf of an entity, multi-signature wallets, etc.
+
+The major security consideration is to ensure only using the standard interface for performing downstream actions or receiving upstream input (vote casting). We expect future audit tool to be based on standard interfaces.
+
+It's also important to note as discussed in this standard that for the sake of simplicity, EIP-1202 is kept in the very basic form. It can be extended to support many different implementation variations. Such variations might contain different assumptions of the behavior and interpretation of actions. One example would be: What does it mean if someone votes multiple times through `vote`?
+ - Would that mean the voter is increasing their weight, or
+ - vote multiple options in the meanwhile, or
+ - Does the latter vote override the previous vote?
+
+Because of the flexible nature of voting, we expect many subsequent standards need to be created as an extension of EIP-1202. We suggest any extension or implementations of this standard be thoroughly audited before included in large scale or high asset volume applications.
+
+The third consideration is non-trivialness. Some voting applications assume ***anonymity***, ***randomness***, ***time-based deadline***, ***ordering***, etc, these requirements in Ethereum are known to be non-trivial to achieve. We suggest any applications or organizations rely on audited and time-proven shared libraries when these requirements need to be enforced in their applications.
+
+The fourth consideration is potential abuse. When voting is standardized and put on contract, it is possible to write another contract that rewards a voter to vote in a certain way. It creates potential issues of bribery and conflict of interest abuse that is previously hard to implement.
 
 
 ## Bibliography
@@ -182,6 +133,8 @@ Here are a few early questions I'd like to ask people here.
  - [Carbon Vote](http://carbonvote.com/)
  - [Paper: A Smart Contract for Boardroom Voting with Maximum Voter Privacy](https://eprint.iacr.org/2017/110.pdf) - *Suggested by @aodhgan*
  - [Private Voting for TCR](https://blog.enigma.co/private-voting-for-tcrs-with-enigma-b441b5d4fa7b)
+ - [Consensus/PLCR implementation](https://github.com/ConsenSys/PLCRVoting)
+ - [Aragon Voting App](https://wiki.aragon.org/dev/apps/voting/)
 
 ## Acknowledgement
 We appreciate Ansley, Andrew, Fred from Enigma, Fan and Raullen from IoTex for sharing us their use cases. we also appreciate the valuable input for designing an EIP from distinguished community members including: @frozeman, @fulldecent, @bingen, @aodhgan.

EIPS/eip-1702.md

@@ -116,7 +116,7 @@ with `version` field being `0`.
 ### Additional Fields in Account State RLP
 
 In the future we may need to associate more information into an
-account, and we already have some EIP/ECIPs that define new additional
+account, and we already have some EIPs that define new additional
 fields in the account state RLP. In this section, we define the
 parsing strategy when additional fields are added.
 
@@ -143,18 +143,18 @@ purpose. When "enabling EIP-1702", those extensions should not be
 enabled unless the extension specification is also included.
 
 - [44-VERTXN: Account Versioning Extension for Contract Creation
-  Transaction](https://specs.that.world/44-vertxn/)
+  Transaction](https://specs.corepaper.org/44-vertxn/)
 - [45-VEROP: Account Versioning Extension for CREATE and
-  CREATE2](https://specs.that.world/45-verop/)
+  CREATE2](https://specs.corepaper.org/45-verop/)
 
 ## Usage Template
 
-This section defines how other EIP/ECIPs might use this account
+This section defines how other EIPs might use this account
 versioning specification. Note that currently we only define the usage
 template for base layer.
 
 Account versioning is usually applied directly to a hard fork
-meta. EIP/ECIPs in the hard fork are grouped by the virtual machine
+meta. EIPs in the hard fork are grouped by the virtual machine
 type, for example, EVM and eWASM. For each of them, we define:
 
 * **Version**: a non-zero scalar less than `2^256` that uniquely
@@ -168,7 +168,7 @@ type, for example, EVM and eWASM. For each of them, we define:
 * **Features**: all additional features that are enabled upon this
   version.
 
-If a meta EIP/ECIP includes EIP/ECIPs that provide additional account state RLP
+If a meta EIP includes EIPs that provide additional account state RLP
 fields, we also define:
 
 * **Account fields**: all account fields up to the end of this meta
@@ -192,8 +192,8 @@ together), then this will requires extensions such as 44-VERTXN and
 
 Alternatively, account versioning can also be done through:
 
-* **[26-VER](https://specs.that.world/26-ver/)** and
-  **[40-UNUSED](https://specs.that.world/40-unused/)**: This makes an
+* **[26-VER](https://specs.corepaper.org/26-ver/)** and
+  **[40-UNUSED](https://specs.corepaper.org/40-unused/)**: This makes an
   account's versioning soly dependent on its code header prefix. If
   with only 26-VER, it is not possible to certify any code is valid,
   because current VM allows treating code as data. This can be fixed
@@ -234,12 +234,7 @@ To be added.
 ## References
 
 The source of this specification can be found at 
-[43-VER](https://specs.that.world/43-ver/). This specification is 
-also realized in:
-
-* Ethereum Classic Improvement Proposals as
-  [ECIP-1040](https://ecips.ethereumclassic.org/ECIPs/ecip-1040).
-
+[43-VER](https://specs.corepaper.org/43-ver/).
 
 ## Copyright
 

EIPS/eip-1930.md

@@ -21,16 +21,44 @@ This is for example the case for meta-transaction where the contract needs to en
 
 But this is also the case for common use cases, like checking "on-chain" if a smart contract support a specific interface (via [EIP-165](http://eips.ethereum.org/EIPS/eip-165) for example).
 
-The solution presented here is to add new opcodes that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert.
+The solution presented here is to add new call semantic that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert.
 
 
 ### Specification
 
+There are 2 possibilities
+
+a) one is to add opcode variant that have a stricter gas semantic
+
+b) The other is to consider a specific gas value range (one that have never been used before) to have strict gas semantic, while leaving other values as before
+
+Here are the details description
+
+#### option a)
+
 - add a new variant of the CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert
 - add a new variant of the DELEGATE_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert
 - add a new variant of the STATIC_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert
 
-In other words, based on [EIP-150](http://eips.ethereum.org/EIPS/eip-150), the current call must revert unless G >= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified.
+##### Rational for a)
+This solution has the merit to avoid any possibility of old contract be affected by the change. On the other hand it introduce 3 new opcodes. With EIP-1702, we could render the old opcode obsolete though. 
+
+#### option b)
+
+For all opcode that allow to pass gas to another contract, do the following:
+- If the most significant bit is one, consider the 31 less significant bit as the amount of gas to be given to the receiving contract in the strict sense. SO like a) if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert.
+- If the 2nd most significant bit is zero, consider the whole value to behave like before, that is, it act as a maximum value, and even if not enough gas is present, the gas that can be given is given to the receiving contract 
+
+##### Rational for b)
+This solution relies on the fact that no contract would have given any value bigger or equal to 0x8000000000000000000000000000000000000000000000000000000000000000
+
+Note that solidity for example do not use value like 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as it is more expensive than passing the gasLeft.
+
+Its main benefit though is that it does not require extra opcodes.
+
+#### strict gas semantic
+
+To be precise, regarding the strict gas semantic, based on [EIP-150](http://eips.ethereum.org/EIPS/eip-150), the current call must revert unless G >= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified.
 
 So instead of
 ```
@@ -103,7 +131,9 @@ Similarly to the the previous solution, an EVM mechanism would be much better.
 
 ## Backwards Compatibility
 
-Backwards compatible as it introduce new opcodes.
+for specification a) : Backwards compatible as it introduce new opcodes.
+
+for specification b) : Backwards compatible as it use value range outside of what is used by existing contract (to be verified)
 
 ## Test Cases