consensysmesh / india-training Goto Github PK

The endContributorPeriod() function should be ideally called by the Contract Creator/Owner or else anybody can end the proposal period. But if we add that, there will be a problem in checking the contract for the Test Cases because then only we(Contract Owner) can call it and Daniel won't be able to check for other conditions.

So , do we have to make endContributorPeriod() call by Owner only or anybody can call it.
PS: In real life scenario, we shouldn't allow anybody to call this but only Owner.

Need one clarification about the Submit Proposal value.

It is mentioned Anyone can submit a proposal by sending a transaction calling the function 'submitProposal` with the requested value. Value cannot be more than 10% of the total holdings of the contract.

What is "total holdings". Is it

1. The amount collected at the end of the "Contribution Phase"?
   OR
2. The amount that is "available" currently. ie, "Total Amount Collected during contribution phase" - "Total amount of value in the approved Proposals" - "Total amount of values in the proposals which are neither approved nor rejected"?

if we go with "1", the code will be simpler. If 10 submitters ask for 10%, then no one can submit. If all 10 get approved, then the contract is "closed"!

if we go with "2", the first submitter can request more than anyone else. it is a "diminishing returns" thing where people can keep submitting, but the values will become lesser and lesser. The contract will take infinite time to exhaust it funds!

Have clarified with Daniel that the contract should also provide a function that will return the owner of the contract (similar to what we did in home work 2)

- function owner() returns (address).

Just posting as an issue for the benefit of others.

In AbstractMultiSig.sol, the following 5 events are mentioned

event ReceivedContribution(address indexed _contributor, uint valueInWei);
event ProposalSubmitted(address indexed _beneficiary, uint _value);
event ProposalApproved(address indexed _approver, address indexed _beneficiary, uint _value);
event ProposalRejected(address indexed _approver, address indexed _beneficiary, uint _value);
event WithdrawPerformed(address indexed beneficiary, uint _value);

can we change the below two events to follow the same convention (I am writing unit test cases and came across this)

event ReceivedContribution(address indexed _contributor, uint _value); // value to _value
event WithdrawPerformed(address indexed _beneficiary, uint _value); //beneficiary to _beneficiary

This is regarding Homework 3. The following is my understanding, please review.

• Contributors - are those who fund the contract.
  Anyone (including creator of contract, submitter of proposal and signers ) can contribute any value and as many times during the "Contribution Phase" of the contract.

• Submitters - are those who submit proposal
  Anyone (including creator of the contract, contributors and signers) can submit a proposal after the end of the "Contribution Phase" of the contract.
  If we allow a signer to submit a proposal, he has an edge over others, because he can approve his proposal. So do we want to disallow signer to submit a proposal?

• Signers - Are those who vote on proposal and who can end the "Contribution Phase"
  The signers are allocated to the contract during contract creation. (while deploying to the Gyaan network for Daniel to test, these are the address's specified in the india-training/June-24/homework/signers.txt file)
  To end the "Contribution Phase", any one of the signer can call the endContributionPeriod() function. Only other requirement is that the Contract should have received some ether!
  A signer can call the approve or reject a proposal. A signer can call only one of these functions and that too only once.
  If the majority (ie > 50%) of signers have called approve function, the proposal is "accepted". If the majority of signers have called the reject function, the proposal is "rejected".

1. Are we allowing multiple contributions from a contributor? This might cause issues, so setting a minimum contribution to vote for a proposal would help. Anyone who wants to vote should first send the minimum contribution and then eligible to vote.

2. Point 1 will ensure that we do not need a function endcontribute () as it would define the minimumcontribution once to vote

3. Who would be managing all the proposals? is there some manager?

1. Anyone can contribute ethers to the contract at any time.

2. This means the amount held in the contract can vary from time to time.

3. When someone submits a proprosal, he can submit value which is 10% of the value held by that contract at that time.

4. A proposal will be in Submitted state, Approved state, Rejected State, Money Completely Withdrawn state or Money Partially Withdrawn state.
   Can the beneficiary withdraw amounts (for the same proposal) at different times? ( The only requirement is that the sum of withdrawal has to be less than or equal to the approved amount).

5. A beneficiary can submit only one proposal at a time?
   He can propose only after his previous proposals are in one of the following states - Rejected or Money Completely Withdrawn state?

6. Can an Approver keep changing his mind by calling Approve or Reject for a given beneficiary as many times as possible (if the proposal is in Submitted state)?

7. Since a beneficiary can withdraw at any time, there is a possibility that the contract does not have enough ether to transfer.
   For eg, 20 proposals were submitted each for 10% of the contract value.
   If all are approved, then there is not enough ethers to provide for all. Whoever withdraws first will receive the ether!!!

8. An "final" approve will fail if there is no sufficient ethers in the contract (for the submitted proposal value)
   say there was no sufficient ether in contract when the first approver "approved", but it will be success.
   but when the second approver "approve's" the contract, it will fail since there is no ether?

In the AbstractMultiSig.sol, value parameter in the Functions and also Events are mentioned as "Ethers".

Just wanted to double check that this is Ethers only and not Wei.

Also a user can contribute to the fund any value (including less than an ether) in Wei.

Wei and Ether support will mean we need to do conversion in code as needed. So wanted to be sure before i write the extra code. (The easiest will be if you allow everything to be specified in Wei :)!)

1. Do we need to use fallback function for contributing Ethers to contract ?
2. Should we check that signers should be the 3 addresses mentioned in singers.txt ?
3. Withdraw should be done only if more approves than rejects ?
4. Withdraw should be done only after 3 singers vote the proposal, should wait for all 3 signers to either approve/reject?
   5.How many beneficiaries can be approved to withdraw ?

In the Readme file, "In the second part, due to other week, you should develop a web interface to interact with the contract."
Is the second part due next week ?

Amit