I submitted a ticket the very moment I found the little error, but I didn’t get any response in 2 days. Is this normal? It’s an emergence but obviously you didn’t take my situation seriously. If I didn’t post on the forum, you won’t reply to me, right? And it’s been 72 hours. Yes, your site does have 2 input and the security code, but most sites have pop-ups requiring the final confirmation when it refers to property. However, you don’t have this. I had contacted with 796 Exchange when I finished transfer and xchang796 doesn’t belong to them. I think it’s a very irresponsible act to say that it might their account. I’m very sad to hear that from you. Moreover, the stuff told me that the account xchange796 was created in no more than 72 hours. I don’t believe that someone would create such a similar account and just set people up to rob their property in such a short time. Do you believe that? I’d like to ask you to provide proof or I’ll take it as a loophole from your platform, especially comes to such a phishing account. You should solve this problem and improve the customer service. They let me wait such a long time and then tell me that you are not able to figure this out. What makes me very angry is that you did not take any action to suspend the transfer during the 72 hours. You’re obviously making an easy way for liars. It’s not what a trustworthy platform should’ve done. There’s a lot of fraud in the internet world. And I guess you guys know this. Only those who try their best to protect users’ property and act for users’ interest can earn users’ trust and respect. Yet, BTCT is doing really bad on this.
I wrote back privately at the same time I responded publicly. I had a limited window of time to respond in and responded as soon as I saw your messages. I hate to say it, but had I seen it 2 seconds after you wrote it -the response would have been the same-. I took your situation quite seriously. However painful it may be that you did not get the immediate resolution you wished, we are not going to get into the business of reversing trades instantly for user input errors. Transfers in online banking to accounts that don't belong to me are instant and permanent. Every single transaction in bitcoin is instant and permanent. This is no different.
Proof that the account exists is simple to test. Grab a share of something cheap and try sending it to a random account. For accounts that don't exist the transfer is rejected. (add: looks like dexX7 tried this.)
I am very, very sad that you sent your shares to a scammer. But let's not turn this into more than it is.
That all said... I'm pretty sure I mentioned in my email to you that I'd look into it. Turns out this user has ~15 accounts, all variations of the 796 exchange's username. It seems to be an obvious scam and I locked the account you sent the shares to yesterday. I'm going to sit on them for a while before returning them on the off chance that any further evidence should surface, but they are secure at the moment.
For example, the "796 Exchange" account would have a hash "1271", but the "xchange796" account would have the hash "4252". If the hash is required to transfer, it would be very unlikely that someone could transfer to the wrong account by mistake because the hashes wouldn't match. It would also be very difficult for someone to spoof an account using a misspelling .
Just some brainstorming on this idea (still not sure if the idea itself needs to be done):
- Every user has a second identificator (4 char hash for example)
- Sender starts transfer to username as usual
- btct.co asks for confirmation and displays username and second identifier
This would eliminate the need of entering the second identifier with almost the same outcome.
The current two times input + pin is much more than we get from a Bitcoin tx though. I tried to send a share to a non existing username and all it shows is "invalid user", so this case is covered already and they don't get lost in limbo.
xubingde: I don't understand the loophole you mentioned and I feel sorry for your loss. What would you like to happen to "solve" your problem?
I like the "transfer pin" idea. Adds some pain to transferring that I'm not sure I'm willing to take on though. Think if it from my perspective (ASICMINER-PT) or Deprived's perspective (DMS.SELLING, DMS.MINING, etc.) ... we do 1000's of transfers. In Deprived's case he's watching transfers come in, which gives him an account id, then transferring back an appropriate number to the same account. Adding a stage where he has to contact the user and request their private transfer PIN would be a deal killer.
Maybe when transfers come in we display the "from" account as "account:transfer pin"... ? Thus you'd have what you need to return the transfer if necessary?
Maybe require the receivers to 'pick up' the transfer by clicking a button, and allow the senders to cancel the transaction up until the pickup point. This allows some window of opportunity for the sender to recover their error after realizing that he entered the wrong information a couple of times, verified it, and then clicked to transfer before it becomes permanent.
Adding a unique hash to each user is a good, but really though, how far you go to account for user error can lead to an interesting cost/benefit analysis where much of your effort is focused on solving for the least common denominator. It's usually more efficient to treat these as one-off cases and fix what can be fixed manually and leave a warning for the user otherwise.
In this case, I think reversing the transaction requires embroiling oneself in the affairs of the transaction -- getting approval from the transfer recipient and confirming that this was transferred to his account by mistake. Otherwise, this method could be used as a 'reversal' technique for legitimate transactions. The easiest way to solve this would be to simply ask the recipient to transfer back the shares they were transferred in error (that is, if he still has them). However, since there's no messaging system between users on the site, there's no way for users to handle this on their own. With admin intervention, if the accidental recipient disagrees that this was an erroneous transfer then this would place the admin into a position as an arbiter, which he shouldn't be in, especially with no legitimate proof either way on whether it was an erroneous transfer. In such a case, I'd have to agree with leaving the transfer alone and not reversing it, since ultimately it's the user's responsibility to confirm that the recipient information is correct before they submit it.
Maybe add a disclaimer about transfers being irreversible.
The "pick up" button idea is a good one, but difficult to implement. Also, who gets the divs while the shares are in limbo?
Regarding one-off cases and fixing these manually, transfers are permanent. As you mentioned, reversing anything requires mediating between the two account owners. I guess mediating something like this is something we could offer to do for a fee, but what response is a scammer going to have other than "those are my shares, of course I paid for them!". This is reinforced by the fact that in 99% of the cases they're going to have already been sold and the coinage transferred out.
I've added a warning to the bottom of the transfers form.
