[BTC-TC] Virtual Community Exchange [CLOSED]

[Ozymandias]

Any chance you can find time to code this simple feature: Issuers own Bid and Ask orders are highlighted so they are clearly visible to everyone.
I have asked this like 3 or 4 times (even when GLBSE was around)
Lets make it even better. if issuer buys back shares, those trades are marked in the trade history.

Why, read about the ActiveMining fiasco, where "new walls are going up" but no idea when and where.

Seconded. Though if this were to be implemented, how would the site differentiate between shares sold by the issuer at a certain price and other peoples' asks at that same price? Would the shares be broken up into two groups "issuers" and "others" with, hopefully, issuers shares getting priority, or would the entire amount be highlighted (thus somewhat ruining the point of highlighting in the first place)?

[EskimoBob]

Any chance you can find time to code this simple feature: Issuers own Bid and Ask orders are highlighted so they are clearly visible to everyone.
I have asked this like 3 or 4 times (even when GLBSE was around)
Lets make it even better. if issuer buys back shares, those trades are marked in the trade history.

Why, read about the ActiveMining fiasco, where "new walls are going up" but no idea when and where.

Seconded. Though if this were to be implemented, how would the site differentiate between shares sold by the issuer at a certain price and other peoples' asks at that same price? Would the shares be broken up into two groups "issuers" and "others" with, hopefully, issuers shares getting priority, or would the entire amount be highlighted (thus somewhat ruining the point of highlighting in the first place)?

We need to see trades, that change the number of outstanding shares and at what price, those happened.
Also, if IPO is in progress, any share transfers (no coin moved via exchange) must be reported or even better, not allowed by default.
 

[Ozymandias]

Any chance you can find time to code this simple feature: Issuers own Bid and Ask orders are highlighted so they are clearly visible to everyone.
I have asked this like 3 or 4 times (even when GLBSE was around)
Lets make it even better. if issuer buys back shares, those trades are marked in the trade history.

Why, read about the ActiveMining fiasco, where "new walls are going up" but no idea when and where.

Seconded. Though if this were to be implemented, how would the site differentiate between shares sold by the issuer at a certain price and other peoples' asks at that same price? Would the shares be broken up into two groups "issuers" and "others" with, hopefully, issuers shares getting priority, or would the entire amount be highlighted (thus somewhat ruining the point of highlighting in the first place)?

We need to see trades, that change the number of outstanding shares and at what price, those happened.
Also, if IPO is in progress, any share transfers (no coin moved via exchange) must be reported or even better, not allowed by default.
 

About your second point, I originally had that written into my previous post, but removed it after the following thought: what if an IPO process takes "too long" and an investor no longer wants their money tied up in that particular venture and is willing to sell at a loss to have his money available to him immediately? Should he be penalized for investing in the beginning/middle of an IPO? Wouldn't that inability to undercut prevent many from buying due to fear of having their money locked for an undetermined period of time?

[xubingde]

Anyone has the same experience as I do?
Yesterday I transferred my shares on BTCT to 796 Exchange. The account should be xchange796, but I missed letter “e” and wrote xchang796. To my surprise, BTCT confirmed the transfer immediately. I don’t believe it’s such a coincidence that there’s an account xchang796 which really exists. Therefore, I filed a ticket. It’s been 2 days and no response from BTCT. What should I do? Anyone who can give some advice?

Hi there.  As mentioned (now a few pages back unfortunately.) I have been traveling.  So I apologize for not getting back to you sooner.  However...

"to my surprise" ... what?  You think people would use it if transfers to valid accounts were NOT transferred immediately?

The form asks, not once, but twice who you want to send it to.  Then, while you're looking at the form, with both users plugged in, you have to put in either your PIN or your 2FA before submitting.  I think I've done about everything I can to prevent mistakes such as these.

Someone else likely got your shares, unless 796 exchange happens to have both accounts, and I cannot undo it.

Very depressing... I try really hard to help people not make these kinds of mistakes.  I am very sad for you. 

 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.

[pascal257]

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.

Nah, everyone is totally honest and peaceful on the internet.

[xubingde]

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.

Nah, everyone is totally honest and peaceful on the internet.

I submit Support Request,  but I didn’t get any response in 2 days. Is this normal?

[Lohoris]

Perhaps a solution is to associate a 4 digit hash with the account name. In order to transfer assets or bitcoins to another account, you have to include the hash.

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 .

Brilliant idea, but better than a hash would be a random number.

If it was an hash and somehow the algorithm became known, you could try offline many small variations until you got one with the same hash.
If instead it's just random, as long as you can't create accounts at will, it should work.

[xubingde]

Anyone has the same experience as I do?
Yesterday I transferred my shares on BTCT to 796 Exchange. The account should be xchange796, but I missed letter “e” and wrote xchang796. To my surprise, BTCT confirmed the transfer immediately. I don’t believe it’s such a coincidence that there’s an account xchang796 which really exists. Therefore, I filed a ticket. It’s been 2 days and no response from BTCT. What should I do? Anyone who can give some advice?

Hi there.  As mentioned (now a few pages back unfortunately.) I have been traveling.  So I apologize for not getting back to you sooner.  However...

"to my surprise" ... what?  You think people would use it if transfers to valid accounts were NOT transferred immediately?

The form asks, not once, but twice who you want to send it to.  Then, while you're looking at the form, with both users plugged in, you have to put in either your PIN or your 2FA before submitting.  I think I've done about everything I can to prevent mistakes such as these.

Someone else likely got your shares, unless 796 exchange happens to have both accounts, and I cannot undo it.

Very depressing... I try really hard to help people not make these kinds of mistakes.  I am very sad for you.  

Perhaps a solution is to associate a 4 digit hash with the account name. In order to transfer assets or bitcoins to another account, you have to include the hash.

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 .

Perhaps a Correct solution

[dexX7]

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?

[parseval]

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.

[burnside]

Hey Burnside.
People are discussing why they will have their future IPO on bitfunder instead of btc-tc here:
http://www.reddit.com/r/Bitcoin/comments/1im2o9/the_bitcoin_based_bank_being_launched_in_cyprus/
I thought it could be interesting info for you.
(you need to scroll a bit)

Interesting point.

I really wouldn't have guessed that such a disclaimer would be considered worse than the horrible security flaws and quirks of bitfunder...

The interesting point in question seems to be this:

cryptocyprus: 14 points 22 hours ago

Bitfunder has a genuine lawyer that our team can work with to ensure everything is legally sound. Our team reviewed BTC-TC and unfortunately if the local media here get a hold of the "Nothing is verified. Everything is virtual." stance it would create a larger set back for us when trying to build trust with the Cypriot people. We have investigated every avenue as a route to secure funding and decided on the most suitable for both investors and our company to proceed with.

That doesn't particularly hurt my feelings.  I'd rather people go with what fits their needs rather than trying to fit a square peg in a round hole.  Plus I value my freedom, so they just gave me a pretty good argument in court if it ever comes down to arguing whether we're virtual or not.  (Judge, we gave up revenue and didn't pursue "real" issues, see here: ...)  There's actually several examples of this to date now, and it's somewhat a relief honestly.

I would be curious to know how they are getting around US Securities Law.  Specifically the part where you're not allowed to market or offer to non-accredited (accredited = net assets of 1 mil and registered with the us gov't.) investors.

Also, if the BF lawyer is not a Cypriot lawyer, then they may be getting dangerous advice.  

I think if I were these guys and were serious about keeping the legal challenges to a minimum I'd be soliciting private investors quietly, not listing on an exchange, but that's just me.

I guess the other consideration is that if the issue is any good, there will probably be someone setting up a PT before you know it.  

Cheers.

[burnside]

I might have spotted some strange behavior in availability checking. I could reproduce this:

1. Own shares
2. Write call options
3. (optional) Cancel options
4. Recall options

= Shares are still reserved.

But they can be placed via API and after canceling the new placed API order, they are available again.

I did this with all shares of an asset. If I only place a portion of them as option and recall, they are still shown as reserved in the order placing window, but the order gets placed the same as via the API. It's problematic, if it's done with all shares, because "there is no way to force the placement" because the buttons are disabled.

It's a cache issue.  The existence of the options is cached and applies against your reserves until it times out.  It's not long though.

Cheers.

[burnside]

Small API feature-request: Add the username to transfers in the trade history. Currently it only says "transfer-out" or "transfer-in", but not to or from who.

Great idea, added to the todo.

Any chance you can find time to code this simple feature: Issuers own Bid and Ask orders are highlighted so they are clearly visible to everyone.
I have asked this like 3 or 4 times (even when GLBSE was around)
Lets make it even better. if issuer buys back shares, those trades are marked in the trade history.

Why, read about the ActiveMining fiasco, where "new walls are going up" but no idea when and where.

Seconded. Though if this were to be implemented, how would the site differentiate between shares sold by the issuer at a certain price and other peoples' asks at that same price? Would the shares be broken up into two groups "issuers" and "others" with, hopefully, issuers shares getting priority, or would the entire amount be highlighted (thus somewhat ruining the point of highlighting in the first place)?

We need to see trades, that change the number of outstanding shares and at what price, those happened.
Also, if IPO is in progress, any share transfers (no coin moved via exchange) must be reported or even better, not allowed by default.
 

We discussed this a couple of pages back.  I think the plan is to highlight issuer orders, then have a checkbox that allows the buyer/seller to fill the issuer's orders before filling other user's orders.

Cheers.

[ThickAsThieves]

I guess the other consideration is that if the issue is any good, there will probably be someone setting up a PT before you know it.  

Did someone say PT?  

[burnside]

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. 

[ThickAsThieves]

Any chance you can process withdrawals today?

[burnside]

Any chance you can process withdrawals today?

Been working on it while responding to posts.  Some today were particularly sticky    I should be back to more frequent withdrawals in a couple days.

[Deprived]

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.

Yeah it would be a total pain for me.  I get the user ID to send to from the list of who transferred.  I use copy/paste to put in my own transfer out so there's minimal risk of me sending to the wrong person.  I can, of course, get the quantity to send wrong - but a pin wouldn't change that.  Obviously I wouldn't object to a pin being added if it was optional.

I plan to automate the exchanging eventually (it can't be done right now even if I had the time - as API doesn't currently provide sufficient information : it lacks the identity of the sender so a bot wouldn't know who to send back to) which would be impossible if there was other information required beyond identity of sender.

Not sure how many transfers I've done for DMS but it must be getting towards 1K sets of paired transfers.  Only errors so far (other than missing a few - which were all caught up with either when my daily audit caught the error or when the user PMed querying) were a couple of occasions where I failed to send 1 of either Mining/Selling (probably clicked transfer instead of pressed yubikey and didn't notice) and one where I sent too few of one.  Oh and on a few occasions I mistakenly sent mining rather than purchase when doing swaps in from my personal account - just force of habit there I guess.

Copy/Pasting name to send to from wherever it originated rather than retyping it is best protection by a mile.

[Lytse]

Why is there a wait time when placing buy and sell orders?

Is the wait time also enforced on the OAuth trade endpoint?

I am asking this because I noticed an active tradebot on a TAT.VIRTUALMINE trade. It seemed that the bot had advance knowledge (about my trades) and a faster trading speed (its trades were processed faster) than I had because of the wait times.

[Rannasha]

Why is there a wait time when placing buy and sell orders?

Is the wait time also enforced on the OAuth trade endpoint?

I am asking this because I noticed an active tradebot on a TAT.VIRTUALMINE trade. It seemed that the bot had advance knowledge (about my trades) and a faster trading speed (its trades were processed faster) than I had because of the wait times.

What do you mean by wait time? My trades always get placed directly. Of course there can be some slowness in loading the site from time to time, but that also affects API-trading I noticed.