Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 136. (Read 316534 times)

I'm all for strategies that reduce the amount of BTC in the exchange wallet.  The BTC in that wallet is a liability to BTC Trading Corp.

Given the confirmation time of BTC transactions, I'm not sure that filling purchase orders with remote coupons or remote funds would work very well.  In your proposal you suggest that users can place a purchase order, but only transfer the BTC when the order is filled.  I think I could accomplish nearly the same thing by setting up notifications triggered when an asset has a sell offer at or below a certain price?  You'd get a notification, transfer the BTC to the exchange, and close the deal.  This would greatly limit your exposure to BTC theft on the exchange.

On the fulfillment of sale orders, I could put in an auto-payout threshold feature similar to my LTC mining pool.  It's very simple.  If your balance goes above a certain amount, it is auto-withdrawn to your preset address.  I like this idea, and it is easy to implement.

There is little to no risk of the exchange operator (me) playing around with other people's shares.  It would be too easily obvious since there is complete visibility to the asset issuers of who has what.  A person making a claim that shares were stolen could go to the asset issuer, who should be able to go back through the emails received (hopefully they're archiving them off somewhere)  and figure out where the assets went.  In a similar manner, the dividends display both the total paid and the payout per share, such that if you check your balance history you can clearly see that nothing is disappearing in the process.  I've gone to great lengths to keep things transparent.

The other thing I'll add is that the MPEx guys (Mircea Popescu?) have a great blog post up here: http://polimedia.us/trilema/2012/a-message-to-bitcoin-wanna-be-scammers/

I think there's more to be made with a legit service than there is with a scam.

Cheers.

Yes, sorry. Mybitcointrade.com doesnt have something to do with burnside as far as i know. The user Mybitcointrade.com is a different entity in this forum. And he ran an exchange that looked normal. When there werent a typical hyip-offer. People warning were there all the time and at the end the warnings were correct.

I wonder if there cant be an exchange that doesnt store btc in itself but instead a user address is used. I mean you create a buyorder then you have to send btc. You get btc from selling a share, then you get the btc directly to your own btc-address outside the website. The same goes for the dividends. You could do the same manually but lazy people wont do, noobs dont know. And manually wouldnt be that fast to take out the btc from there.

Then the amount of btc that are there able to be stolen are held at a minimum all the time. Plus, when its ensured that the issuer always have an actual list of shareholders even when the website is stopped the next point is solved.

The only risks then would be that you buy shares that arent real. The issuer runs with the money or so. Such an security could be created from a scammy exchange owner too.

Second risk would be that the exchange-owner is messing with the numbers. Selling shares from legitimate issuers that dont know about that and cant prove it because the numbers they get only show the correct amount of shares. That could become a real bad problem if someone would have this criminal energy and still can create the trust to use such an exchange. This only could come to light when the userlist holding shares is opened to the public. But only when a user that bought such wrong shares would check this list it would come to light. Not all users would do this.

MPEx doesn't need or really use two-way email communication. It's one way, you send your public key.


Depending on the exact configuration, this may be true. If it's a concern the solution obviously is not to use your desktop for signing. This is something that one can do on MPEx but can't do on a plain website, which is why the plain website NEEDS some form of 2FA: to try and replicate what MPEx does natively.


Yes, as described in the MPEx faq: get an offline computer, sign there.

Next question I suppose...

Would it be possible to reasonably combine gpg + 2fa?

In SMTP it's on the recipient to choose how secure they want to be.


Incorrect.



If you go back I was responding to your sentence listing "usernames" as things I might be including in the email.  You have a way of quoting just enough to confuse people.



I have read them thoroughly.  It is a completely different issue.  The lists goat received did not include email addresses, which are independently verifiable vessels of ownership.  There's no way someone can claim the same shares twice from the same email... 


I definitely appreciate the input.  Perhaps it's the barbs that come with it that ruffle my feathers.



Eh... this one confused me.  How do you propose using someone else's email address and still achieving two way communication?  Either you receive mail at the address (rendering it yours, whether you stole it or not) or you do not.  Sure, spoofing an outgoing message is easy enough, but it is not so easy to receive the reply.


Please do not take my criticisms as an attack toward your user base.  It clearly takes a knowledgeable individual to trade on MPEx.


Your comment about passwords being leaked is kind of the point behind 2FA such as google authenticator.  If your password is leaked, it's not the end of the world.  (I suggest reading up on yubikey/google auth.)

I also do not think the MPEx is as strong as you think it is.  Linux is great, but certainly not without it's issues.  (been using it for a desktop over 15 years now.)  Bottom line is that with MPEx if your desktop is owned, you're owned.  Both of the pieces required to trade (key + pass phrase) would reside on the machine if the attacker is reasonably intelligent enough to install a keylogger.

Cheers.

Do you actually somehow enforce your email delivery over SSL only? Otherwise the fact that it can go over SSL doesn't help in this discussion. Maybe look into S/MIME if you're really decided on this email thing and it isn't just a quick hack tacked on in the wake of GLBSE without any structural consideration.


As far as I know email addresses can either be safe or anonymous. There's no way for someone to have both.


Well, in general that can't be a bad thing. But let us concentrate on the problem at hand.


You're asking me as if I'm proposing this. I am not.

If you are in fact doing something like that, the problems are too many to list.


This happens to be false. The problems have been amply discussed in the Goat delisting threads, please look there.


The latter is probably a good idea. At the very least it offers a little more footing for the "user's fault" line. Probably even better would be to make the mailings opt-in rather than opt-out (which is general policy with mailings).


I'm not sure personality enters into it, but if you think so by all means, try it out. The only thing with computer programming is that it scarcely ever makes sense to do anything half way. Zero, one, infinity is the rule.


Yes, and this openness pays you the dividend that people who otherwise wouldn't be interested or know enough to comment can point out (free of charge) what they perceive as problems with your designs. You're the recipient of a gift not the accused of a crime, simmer down.


This is absolutely not the case. In fact, I could use your email address to register an MPEx account, and while you'd know I emailed something to MPEx so you could maybe guess it's a new account if it is anything at all, you couldn't find out if I had or have funded it, bought anything, etc.


A used laptop which you can format and dump some sort of Linux on is maybe 100 dollars. But that aside, people dealing straight on MPEx are a lot better capitalized and a lot more sophisticated than you seem to imagine.

In any event, note that the need for 2FA on a website is different than the need for 2FA in GPG based systems such as MPEx. There are numerous ways in which the password to a site can be leaked, such as XSS attacks (which are probably the most common). In and of itself the GPG passphrase even if acquired does nothing: you need both the passphrase and the secret key to do anything. Obviously on Windows this difference is mostly meaningless (I think?) because he who has any sort of sniffer installed also has full access to the disk. On Linux this can be quite a different story. But in any event: making MPEx stronger than the user's GPG signature serves no purpose, because once the attacker acquires the ability to GPG sign with the user's signature he can already issue signed obligations which are strong enough to be enforceable.

No worries.

Continuing...


An email address != identity.


Email transit over SSL has been around and in common use for the better part of the last decade.  I thought over at MPEx you guys were all up to date on this encryption stuff?

And when the email list is snagged off an asset issuers hard drive, (more likely than interception) so what?  It's a list of email addresses.  It's not a list of identities.  Last time I checked email addresses were available anonymously for anyone that wanted them.


It's not perfect.  We don't have signed receipts. (yet)  I've been working through how to make such a feature easy to use.  However overall it's a marked improvement over GLBSE in usability, which was itself a night and day improvement over MPEx usability.  It has sustained months of constant probing and the risk in operating an exchange with good backups is minimal.  The coin in the wallet is a drop in the bucket in comparison to the securities represented on the exchange.  I am not going to go into details regarding the security features I've built into the system, but I will say that I have put significant dev time into making sure things are well protected.


What good would a username be?  Or a code?   

An email address and share count is all you need when you have a trustworthy source for the list.  Any failure of the email address system would be a failure of the asset holders by allowing their desktop to be compromised, the email account to be compromised, or by not keeping their address up to date.  incidentally... this is not unlike the exposure to trading on MPEx... As I understand it, if your desktop is compromised, so is your MPEx account and shares.*

I've been considering adding the withdrawal addresses to the list, which would only bolster the usability of the list in a shutdown scenario.



I'll consider making encrypting the mailings an option.  I'll also consider an option to turn off the automated mailings.  (We do after all offer an API option for pulling the data.)  The exchange is definitely a work in progress.

I suspect that you may be making a mistake in assuming that I am trying to be all super-secret like MPEx is with the whole "you can be as anonymous as you want to be" bit.  I am quite the opposite in terms of personality... I am open and honest about what I expose and to whom this information is exposed.  I tell everyone that the asset issuers get a list of email addresses.  I am not bashful about this fact, and purposefully publish this so that our users can decide when they sign up for an account how anonymous they want to be when dealing with us.  This simple fact renders a user's exposure on BTC-TC nearly the same as a user's exposure when signing up for MPEx, which incidentally deals with you using... your email address.   


* As I understand it, MPEx does not utilize any form of 2FA?  Owned computer = owned MPEx account.  In fact, per your own FAQ at http://polimedia.us/bitcoin/faq.html the only way to legitimately protect your MPEx account is to never ever connect your PC to the internet.  (Or plug in a floppy drive, cd rom, or usb stick into it)   Exactly who has one of those PC's just sitting about?

Cheers.

Oh I see, OP's somewhat dubious English led me astray, I read that as if it were the same person.

Sorry about that.

Perhaps if you include the full context as not to warp anyone's possible interpretation...


It becomes clear that:

Yes, I've been registered here roughly six months.

Yes, someone else I know nothing about started a website I know nothing about, and horrors... was registered longer than I was.

Cheers.

Is this a fact?! What's the story there?


This is actually a pretty stupid idea. For one, if people lose email accounts (happens all the time for umpteen reasons) you'll be leaking user identity. For the other, email works over plaintext, which means even if nobody loses their email account your traffic can be (and once the exchange becomes worth the mention, will be) intercepted, rendering the entire scheme a sort of "public holdings" but for just a part of the userbase (those with the tech to leech you or the money to pay to be in the leech-club). This info asymmetry is already a big enough problem to suggest you don't really know what you're doing with an exchange* (which is not! the same as you don't mean well). For the third, if the info you're mailing isn't actually enough for a claims process (just a username, or some username + code a la Nefario/goat) then it's not actually useful. If the info is however good enough for a claim, Jeebus! re-read this paragraph.

If you want to make a public database exchange just publish the database. If you don't want to make the database public then at the very least encrypt the mailings.

*Leaving myself an out here seeing how last time it seemed you don't know what you're doing I had actually misunderstood what you were in fact doing.

Dev update:

Market: new "Trades" tab, shows last ~48 hours of trades
Market: slight tweaks to moderator score display
Market: split tabs left and right to improve usability
All pages: large tables: subtle alternating row colors
All pages: improved caching on several key functions
All pages: darker font, lighter table backgrounds

Thanks. I made use of this for a fund I was shutting down.

Just to promote my own idea a bit more, the strongest use cases I can see are:

• Place orders, then deposit coins - Why wait for deposits to confirm when you can place orders now; orders would become active as they're funded by deposit
• DRIP investing - as above, orders are placed as they can be filled as dividends are paid out, whole shares only (Placing a order at the maximum price you're willing to pay would let you buy anything at a lower price, ie market price)
• Range trading - Anyone fairly confident of the future price of an asset could place a lower and upper bid and profit from volatility; orders would be bought and sold back and forth as funds or shares became available

As far as I can tell though you'd basically have to show the portion of the order that is currently funded instead of cancelling everything, the API may also need a flag for "View Funded" vs "View All" (probably defaulting to the former). Though that's lower priority. Such a system would also allow more automatic trading without intervention (buy some of X, sell old shares of Y, now more shares of Z can be purchased based on previously unfunded order). Hopefully this would be closer to the silver bullet of providing liquidity, though only across the whole exchange, each individual asset could still fly around pretty quickly.

The only drawback that jumps out at me immediately and painfully is spam bids stay around longer now, maybe force bids to be within a certain multiple of current market values? Or just hide such orders from view. This might just be a separate feature request in it's own right.

That actually doesn't sound like a bad idea.  If I introduce an active/inactive or funded/unfunded status to orders, then the auto-cancel would just deactivate orders that are NSF.  Then all you'd have to do to get your order back would be to make a deposit.  Deactivated orders would not show in the order book, thus would be the same status as cancelled orders.

I'll think about it.  It might be a bit more work than I can tackle for a while.

Cheers.

Dev update:

- Forced buyback is now available.  For the asset issuer it will show up below the bids section of the order book.
- Small tweaks to the purchase/sale emails.

The only way I can think to do it is to allow unfunded orders and to just hide them until there are enough funds to back them again, but that would require several changes and would probably not work well with cancel on order.

Sorry, that was some poor English on my part.  I was wondering what input they let you make when turning on the auto re-investment.  You pretty much answered that though.  Sounds like it just auto-reinvests at market cost, which definitely would not work for us until there's more volume.

Definitely worth keeping in mind though.

Cheers.

I don't understand the question ("all questions"?). Could you re-phrase, please?

There's no limit to set. All you have to do is inform them that you want dividends re-invested. Once dividends are paid, stock are bought at market. They do partial stocks too, I.e. dividend paid 〓 1; stock price 〓 2; you get 0.5 stock. There's no commission on such re-investments.

Yeah, would definitely need more volume.  Also would need pre-set limits I suspect.  What all questions does your RL trading account ask when setting it up?

Cheers.