Automatically merged updates to draft EIP(s) 1202 (#2480)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

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.