{"action":"created","issue":{"url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/2","repository_url":"https://api.github.com/repos/BitySA/whetcwithdraw","labels_url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/2/comments","events_url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/2/events","html_url":"https://github.com/BitySA/whetcwithdraw/issues/2","id":172565699,"number":2,"title":"various issues noted by @ledgerwatch on DAO SLACK","user":{"login":"usukan","id":15863458,"avatar_url":"https://avatars.githubusercontent.com/u/15863458?v=3","gravatar_id":"","url":"https://api.github.com/users/usukan","html_url":"https://github.com/usukan","followers_url":"https://api.github.com/users/usukan/followers","following_url":"https://api.github.com/users/usukan/following{/other_user}","gists_url":"https://api.github.com/users/usukan/gists{/gist_id}","starred_url":"https://api.github.com/users/usukan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/usukan/subscriptions","organizations_url":"https://api.github.com/users/usukan/orgs","repos_url":"https://api.github.com/users/usukan/repos","events_url":"https://api.github.com/users/usukan/events{/privacy}","received_events_url":"https://api.github.com/users/usukan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-08-22T22:01:22Z","updated_at":"2016-08-24T15:45:13Z","closed_at":null,"body":"https://thedao.slack.com/archives/child_dao_community/p1471863396001669\r\n\r\nfirst comment: please use return values of 'send' function to make sure that events are not created if Ether is not sent. Later analysis based on events is easier than based on transactions, but events have to be reliable\r\n\r\nif you use a recent version of Solidity compiler, it will give you warning if the results of send is not used\r\n\r\nin the commonWithdraw function, please use curly braces after 'if' consistently throughout. Also, please use 'throw' consistently throughout instead of 'return'\r\n\r\nand I would remove 'claimingRemaining' function, because escape hatch can achieve the same and even supersedes it\r\n\r\nAlso, I did not see any reentrancy protection, that needs to be clearly in sight"},"comment":{"url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/comments/242112967","html_url":"https://github.com/BitySA/whetcwithdraw/issues/2#issuecomment-242112967","issue_url":"https://api.github.com/repos/BitySA/whetcwithdraw/issues/2","id":242112967,"user":{"login":"BitySA","id":17256247,"avatar_url":"https://avatars.githubusercontent.com/u/17256247?v=3","gravatar_id":"","url":"https://api.github.com/users/BitySA","html_url":"https://github.com/BitySA","followers_url":"https://api.github.com/users/BitySA/followers","following_url":"https://api.github.com/users/BitySA/following{/other_user}","gists_url":"https://api.github.com/users/BitySA/gists{/gist_id}","starred_url":"https://api.github.com/users/BitySA/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BitySA/subscriptions","organizations_url":"https://api.github.com/users/BitySA/orgs","repos_url":"https://api.github.com/users/BitySA/repos","events_url":"https://api.github.com/users/BitySA/events{/privacy}","received_events_url":"https://api.github.com/users/BitySA/received_events","type":"User","site_admin":false},"created_at":"2016-08-24T15:45:13Z","updated_at":"2016-08-24T15:45:13Z","body":"Hello Usukan,\r\n\r\nThank you for reposting ledgerwatche's comments from the DAO Slack. We had already seen his comments and already addressed most of them in the latest commits.\r\n\r\n>  please use return values of 'send' function to make sure that events are not created\r\n\r\nIs already done.\r\n\r\n> please use curly braces after 'if' consistently throughout.\r\n\r\nIs also done\r\n\r\n> Also, please use 'throw' consistently throughout instead of 'return'\r\n\r\nThis is not a matter of style but of functionality. If no state altering changes happen it should be fine to simply use `return`. This way you don't rob the user of all of the gas he is using for the transaction. If on the other hand you want to make sure that the entire transaction is rendered invalid then you should use `throw`.\r\n\r\n> and I would remove 'claimingRemaining' function, because escape hatch can achieve the same and even supersedes it\r\n\r\nYou must have noticed that they have 2 different multisig addresses. The escape hatch  can be used at any point and will only serve as an emergency, while the remainingMultisig can only receive funds 6 months later. The same people will not be the owners of both the escape multisig and the remaining multisig.\r\n\r\nFor the escape hatch we may ask trusted people in the community to become signatories of that multisig. The reason is that the `escapeHatch` will function as a security switch of the contract but could also be misused and no single person or entity should have the power to control the funds in case such a thing happens.\r\n\r\n> Also, I did not see any reentrancy protection, that needs to be clearly in sight\r\n\r\nCould you specify in more detail what kind of protection you are looking for? Re-entrancy protection as in being careful about the order of accounting and sending out funds? Or something different?"}}
{"actor":{"display_login":"BitySA"}}