{"action":"created","issue":{"url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/235","labels_url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/235/labels{/name}","comments_url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/235/comments","events_url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/235/events","html_url":"https://github.com/bitpay/bitcore-wallet-service/issues/235","id":85916688,"number":235,"title":"Potential problem: Hacker locks out funds.","user":{"login":"dabura667","id":6586275,"avatar_url":"https://avatars.githubusercontent.com/u/6586275?v=3","gravatar_id":"","url":"https://api.github.com/users/dabura667","html_url":"https://github.com/dabura667","followers_url":"https://api.github.com/users/dabura667/followers","following_url":"https://api.github.com/users/dabura667/following{/other_user}","gists_url":"https://api.github.com/users/dabura667/gists{/gist_id}","starred_url":"https://api.github.com/users/dabura667/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dabura667/subscriptions","organizations_url":"https://api.github.com/users/dabura667/orgs","repos_url":"https://api.github.com/users/dabura667/repos","events_url":"https://api.github.com/users/dabura667/events{/privacy}","received_events_url":"https://api.github.com/users/dabura667/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-06-07T16:40:31Z","updated_at":"2015-06-08T11:37:30Z","closed_at":null,"body":"Let's say there is a 2 of 3 wallet with keys A B C\r\n\r\nA is on a server, automated through bwc\r\nB is on the CTO's cell phone where he checks manually when he gets an email notification from BWS.\r\nC is held by a trusted third party and not actively followed, as sort of a backup.\r\n\r\nServer is hacked and hacker gets A. Locks up all funds, and runs a script to send another proposal immediately after it gets rejected.\r\n\r\nB wants to be able to create a proposal before A locks them up again, so that he can move the funds to a secure wallet.\r\n\r\nSuggestion: Does BWS have failsafe in place to say \"If A's txp was just finally rejected / removed by A, he can not create another txp for 1 minute\", or something like that? If not, I think it should have some feature like that.\r\n\r\n(My other thought was to remove the \"locking\" feature all together and allow conflicting proposals, and conflicting proposal that's input was spent successfully is automatically purged... but I remember talk here about \"what if someone takes the partially signed transaction and signs it later even though their rejected in-app?\" etc... so I don't know if we should revisit that, or if a time delay would be best.)\r\n\r\nThe only time I could see someone legitimately wanting to re-do a proposal quickly is when it is the creator deleting a txp he created less than 1 minute ago (\"Oops, I forgot this\" type thing)... but if someone just got rejected by everyone, or deletes a txp that already had a reject (pull request pending, I know) then they should be forced to wait 30 seconds - 1 minute so other people have a chance to make a proposal."},"comment":{"url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/comments/109958727","html_url":"https://github.com/bitpay/bitcore-wallet-service/issues/235#issuecomment-109958727","issue_url":"https://api.github.com/repos/bitpay/bitcore-wallet-service/issues/235","id":109958727,"user":{"login":"isocolsky","id":2073468,"avatar_url":"https://avatars.githubusercontent.com/u/2073468?v=3","gravatar_id":"","url":"https://api.github.com/users/isocolsky","html_url":"https://github.com/isocolsky","followers_url":"https://api.github.com/users/isocolsky/followers","following_url":"https://api.github.com/users/isocolsky/following{/other_user}","gists_url":"https://api.github.com/users/isocolsky/gists{/gist_id}","starred_url":"https://api.github.com/users/isocolsky/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/isocolsky/subscriptions","organizations_url":"https://api.github.com/users/isocolsky/orgs","repos_url":"https://api.github.com/users/isocolsky/repos","events_url":"https://api.github.com/users/isocolsky/events{/privacy}","received_events_url":"https://api.github.com/users/isocolsky/received_events","type":"User","site_admin":false},"created_at":"2015-06-08T11:37:30Z","updated_at":"2015-06-08T11:37:30Z","body":"I actually agree with @dabura667 on this. One of the goals of BWS was to shield copayers from attacks (spamming, DoS, etc) comming from other copayers. Funds should always go where quorum decides.\r\nHaving said this, I am not sure this is a priority right now. Things like better backups and alternative ways to move funds not relying on BWS are more important. Once that is done I would revisit this issue and implement some type of DoS prevention check.\r\nRegarding removing the locks: I don't think there is a way to make this intuitive to the user from a UX point of view. Also, a malicious copayer could spam the server with tx proposals if they are not constrained by available UTXOs. So we would still have to implement some checks."}}