I'm the creator of Bitcoinica. I'm not so established here. To be honest, I'm only 17.
Please try it out. (I can pay $1 for you if you're not willing/able to deposit, email me at info@bitcoinica.com. :-D ) You can leave any suggestions, comments, bug reports and feature requests here. I'll look through every single comment. Thanks!
Yes, I have to admit that during testing, I have spotted several errors and these may cause financial losses. Because of this, I have even deleted some features which many people consider useful (such as BTC deposit/withdrawal).
Security is a key concern for a financial system. I totally agree with your point.
The Bitcoin market is filled with exactly highly intelligent people. I will definitely pay attention to every single detail.
(If you see any bugs please email me. I will definitely appreciate that!)
Doing your best probably isn't enough. To have any hope you'll have to hire expensive security people and buy lots of insurance.
All you need in order to be exploited is to be using software with 0day exploits. Many known exploits are not public. In a very real sense, you are only protected to the extent that you are a small target.
As the potential payoff of a hacker approaches $1 million, the likelihood of being hacked approaches 90%. Software really is THAT insecure and bitcoin thefts are not prosecuted making it basically risk-free to steal bitcoins.
I've worked on financial systems before. As others have stated, if you're dealing with real money, then you have a big bulls-eye painted on your forehead, and you need to make sure that your system is hardened.
I don't know if you're already doing these things, but I'll just throw them out there and let you ignore them if you do.
Make sure you understand attack vectors and protect against them. XSS, SQL Injection, man-in-the-middle, etc. Make sure your passwords are salted and hashed.
Auditing. Can't emphasize this enough. Things will go wrong, and when they do, you need to be able to tell when, where, and why. In our case, we had shadow tables in our database where we logged changes, and then consolidated and exported that data into an auditing system. We could confirm that a user made X change at Y time from Z IP address.
Also, a bit of a newbie mistake that I see from time-to-time. Don't use double or float with money.
You can choose which features you use. For instance, I've never used the single sign on/access token functionality. The reset password, account lockouts, etc. are awesome.
Unfortunately, seeing his age put me off depositing money into the account I just created. When dealing with my money, I want a team of people with a lot of experience in security and dealing with problems under pressure. He may have this, but at 17 its unlikely. My quick evaluation may be unfair, but I'm unwilling to take that chance with money, especially after MtGox showed us all what kind of problems could occur if not enough work is put into preventing potential problems.
So, at least for now, I'll pass. Having said that, the site looks great and I wish the creator the best of luck and lots of success!
When I first decided to disclose my age, I have considered this problem. Actually this is a psychological paradox: proving myself honest doesn't always make me more trustworthy.
It's just like the warranty of your gadgets. Getting a wonderful repair service may make you feel better than having no problem at all.
I have no problems with this kind of thinking. It really doesn't matter to me. I'll prove my competency with time.
To be honest, your age isn't a problem, because the average above-average developer is still not competent to write this sort of software. If you had been doing security and financial software since birth, I might consider putting a bit of trust in the kitty to start.
I'm going to pitch a different take than a few others: Yes, great initiative, please keep trying things and building things, but end this project now. There are no probable outcomes where you do not end up having to explain where thousands of dollars of other people's money went to some angry people. There's also very nontrivial odds of being on the wrong end of armed Federal agents, based on some of the other comments you've made here. This is a horrible, horrible first-project sort of project.
Let me put it this way: Would you be willing to convert the BitCoins in your system into cash, put it in your front window, and post daily pictures of the pile of cash to your Facebook account, set to public visibility? Because that's roughly what you're doing.
You're very smart, zhoutong, and your eager and polite acceptance of feedback does you great credit. But I would not attempt what you're doing, and I know a fair amount about both trading infrastructure and security.
And though your site is very impressive, I immediately spot a major omission: you say nothing about your margin call policy. Do you have one? What will you do when one of your users' accounts goes to zero, and then negative?
Yes, we have. I admit that I didn't make it visible on the site itself. But the system checks every single user every 5 seconds.
We have two metrics: net value and minimum net value. When NV < MNV, all positions are immediately liquidated. When NV < 2MNV, a warning is visible on trading panel. (Future feature: margin call email)
These metrics are completely transparent, showing in different colors to represent health status. Once you give it a try you will know.
Its not so much about proving yourself honest as proving yourself competent and skilled enough to deal with potentially disastrous (read: bankrupting) problems. If this site didn't deal with money (and potentially a LOT of money), my attitude would be very positive. The site looks very slick and well made.
Its also not really about your age either - but age is a simple indicator of experience, even if inaccurate.
I like your attitude though and wish you all the best.
I started my first startup when I was 17 (13 years ago, damn).
The problem I had then, and you have even here is that legally you're a minor and can't sign contracts.
EDIT: I noticed from your resume that you are based in Singapore - I don't know what the rules are for age of majority and similar issues... the advice below is from a US and UK law perspective given that is the more common location for people on HN. I also notice you seem to be incorporated already (which you wouldn't legally be able to do in US at 17).
Aside from the technical issues of 'spectacular failure' you might want to consider the consequences of being sued if something did go wrong. As a minor, it's probably your parents that are liable - you owe it to your parents and to your customers/users to be aware of this.
Normally for something like this you would set up an LLC to protect yourself (as they have limited liability, as the name suggests). Perhaps your parents can set you up an LLC and transfer ownership when you turn 18?
Issue #1: Singapore MOM (Ministry of Manpower)
Although your company is in Delaware you are running a business operation in Singapore, for which I'm sure you don't have a work permit, as you are in Singapore as a student.
Issue #2: Singapore MAS (Monetary Authority of Singapore) I'm willing to bet these guys would want to get clarifications about what you are doing. You are running what could fit either the Security Exchange category or the Gambling Establishment category. I assume you are not registered for neither of them.
Issue #3: Citibank Singapore
You are receiving business payments into your personal bank account at Citibank in Singapore. Again, I'm willing to bet somewhere on the Terms & Conditions you signed when you opened your account, it says you cannot use the account for business.
Note that in Singapore, failing to solve any of the 3 issues could result in:
#1 - Your student visa being revoked
#2 - Legal prosecution
I'm surprised that you having lived in Singapore don't know how strict the Singapore government would be about something like this. I can tell that you are technically gifted but I think your 2 'adult partners' really ought to have informed you about these issues.
Reduce the attack surface area. The less features the more secure. Since you are already RESTful, isolate the nice-to-have functionality from the main application.
The problem lies on margin accounts. If you use any Forex brokerage platform to trade Euro, for example, you won't get the actual Euro anyway. What you get is still US Dollars when you close your positions.
Of course, it's easier to withdraw in BTC. But it isn't too difficult to redeem in Mt. Gox and buy Bitcoins as well.
I'll try to see if BTC withdrawal is useful. But by any means, Bitcoinica is designed for trading (both investing and speculating), and the accounting currency is always USD. This makes margin trading, short selling and all kinds of complex orders possible.
I don't want to use mt.gox, I moved all my money out of them because the way they treated me and other customers, blocking my account and my money for a lot of time; that's why I'm searching for an alternative exchange.
There is another in closed beta; I can't remember the name because I keep missing their enrollment windows. But when I get to my email account I can post it here.
http://ruxum.com (also http://campbx.com). Fwiw, I've seen one or two posts over on reddit.com/r/bitcoin offering invite codes to Ruxum in the past few weeks.
Since PayPal is reversible, we don't support it currently.
However, there's something that comes into my attention: do fraudsters have any incentive to deposit money fraudulently on a trading platform? What if I limit the account's withdrawal feature for 30 days?
This seems far more advanced than usual for Bitcoin. Nice!
I have little insight into the security of your software, but I hope you have also considered the peculiarities of Bitcoin. To name just one thing that would be far harder in a normal market: open a Bitcoinica account, deposit $10 000, buy $50 000 in Bitcoin, sell BTC really expensively at Mt Gox as the system frantically tries to rebalance. Given the volatility of BTC, this may be profitable even if[1] you subsequently abandon the Bitcoinica account (which is likely to hold $-40 000 in dollars and less than $40 000 in BTC at un-spiked prices...)
[1] EDIT: Actually, it's only profitable if you can get the Bitcoinica account into the red. But given enough ability to move the market, that's definitely possible.
Honestly speaking, I haven't considered this because at first, it's hard to find anyone willing and able to deposit $10,000 (Mt. Gox limits withdrawals, including redeemable codes. Can be lifted though.) Even if that happens in reality, I have already designed some counter-measures:
- The system will automatically break large orders down to 50 BTC increments in a chain. Execution of new orders in the chain will require validation of status of previous rebalance process.
- Limit orders won't be executed further, because the price must increase.
- Market orders will be executed at higher and higher prices, and due to low liquidity, the spread will be larger too.
- The user will run out of margin very soon.
Since I mention that Bitcoinica guarantees liquidity, measures like this must be implemented. Hopefully they are useful to counter malicious trading attempts too.
I'll think about this in detail though. Will further refine my algorithms before the launch of Trading API (which is very dangerous if the algorithms are problematic).
Well, wonderful suggestion - I'm trying to break your scheme for my own amusement. ;-)
Note that the attack works fine if the system allows me to keep buying BTC at, say, Mt Gox' price plus 10%. (For values of "works fine" which handwave a lot of practical issues, like paying you untraceably and making sure that I don't get undercut at Mt Gox too often.)
Maybe you should switch to 1:1 leverage for all accounts once the total balance goes over $1000 until you've had some time to think this kind of thing through?
EDIT: you also want a security@ account and a PGP key. I'm also happy to remove this discussion if you'd prefer that; I arguably shouldn't have posted the first post publicly.
There is zero chance that someone who believes they are getting security out of hosting on Heroku and using Rails (because it has force_ssl and protect_from_forgery) is going to build a secure trading application.
I admire the ambition and for this stage of his career he's obviously cleared the bar, but it's also good for him to learn that in the real world security isn't graded on a curve, and people with more time and experience than him have failed to secure Rails apps.
A brand new financial trading platform written by a lone teenager in China? Here let me give you lots of my money! Not. :-)
Somewhat tongue in cheek. I wish you luck and admire your effort, but advise you to be humble about your skills and pay massive attention to the security aspects of your creation, and certainly engage outside experts who have much more experience in this area. Otherwise you are likely heading to a big public security/financial mishap.
The site looks great! However, what I'd really love to see in a platform is not advance trading features, but an easy way to convert USD to BTC and vice versa. I realize that this is a real challenge given the anonymity provided by the Bitcoin network and the only real instant transfer of money is through credit cards (which like to chargeback). If someone would solve this problem, you have a winner.
We've been in business for a few months now, and don't want this to sound too sales-pitchy, but our customers all love us because converting used to be such a headache. For payment methods, we don't accept credit cards (for chargeback reasons as you mentioned), but we do accept prepaid debit cards, and we have Dwolla, MoneyPak and Western Union as "instant" payment options.
This is a bit off topic, but the FAQs on your website recommend that people insure shipments of cash. As I understand it, UPS/USPS/Fedex will not insure cash or cash-like items. You should look into this so that you don't misguide your customers.
Thanks for the correction. I was at the UPS store the other day and this guy wanted to insure $10,000 in cash he was mailing to his nephew. He wanted to mail the cash to keep it off the record and out of the view of the IRS. The people working there said UPS and FedEx wouldn't insure cash. But, apparently the government will.
There are no technical reasons why this easy conversion can't be done, only legal/beurocratic ones. To do that you'd need to change some laws about money laundering. That's pretty damn hard, so it's highly unlikely to happen.
Very very cool! The idea is great and the interface looks slick!
However, what do you do in terms of protecting people's accounts? You say that the money is stored in your account? Gasp! How do we know you can't turn around and take all the money?
Also, what do you do to protect the accounts from a single rogue trader? If someone deposits money, margins up and loses a bunch of money, how do you protect the rest of the accounts?
I have replied several comments about the security issues. Maybe you can take a look at them.
For the margin trading problem, we liquidate positions by force when the user's net value falls below maintenance. All data is transparent and you can see how far you are from being taken over.
I already mentioned below that I thought your site was nicely done. But you didn't answer my questions directly which makes me a bit wary.
My questions aren't site security questions per se, they deal more with the business of your site. Also, my questions are blunt, but not disrespectful, so don't be offended.
1) How do I trust you? How do I know you're not going to run away with all my money? Who are you?
Registered brokerage accounts have segregated funds, so that brokerages can't get access to my money in case the brokerage goes under. You are saying everything is in one giant account. In the case you suffer a catastrophic loss, how do I know my money is safe? Also, how do I know you're not Madoff and won't run away with all the money?
2) How are you affording the ability to margin people's accounts? Where are you getting the money?
3) You say you check for margin requirements every 5 seconds? If I were a market manipulator, I would wait for the order book on BTC to thin out, then I would massively short the markets. This would hopefully trigger massive margin calls on your end, and forced liquidation. Since the order book is thin, I would probably be able to cover at rock bottom prices. Also, presumably you (the site) would suffer tremendous losses.
1. We can almost never be a registered broker for Bitcoin trading. There's almost no law regulating this market either. If you can't trust me now, it's all okay. I have never asked for trust. What I do is to write apps in the way that people feel trustworthy and reliable. If after, say, 3 months, my site grows larger with no known security issues, then the time will make it more trustworthy.
2. Not all people are doing long or short at the same time. Not all people are utilizing their margin fully at the same time. Not all people have active positions at the same time. We have a pool of money to make this possible.
3. Bitcoinica is not an Exchange. We don't match orders ourselves. The rates you see are inclusive of liquidity concerns. If there's excess positions, we trade them in Mt. Gox to balance our portfolio. When the order book is so thin that you can already move the market with your short positions, chances are the forced liquidation has already taken place. (Thin order book -> larger spread -> lower buying rate)
Yeah, I understand your concern. Bitcoinica has several features/characteristics that make itself like no other:
- There's no Bitcoin wallet. Most incidents happen with stolen or lost wallets. Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox).
- Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc)
- No account minimums. If you're unsure, you can deposit $1 first and try to do some trades.
- Margin trading. This reduces risks. You don't have to deposit 100 BTC worth of USD when you want to long/short a 100 BTC position. 20 BTC is enough. Only when you lose a lot, you can consider adding more margin.
I think trust is a common problem for all websites like Bitcoinica. That's why we designed the platform in the way that attempts to solve the fundamental problems.
There's instant deposit and withdrawal too. You can transfer money from Mt. Gox when you want to trade and transfer it back after you close your position. (Assume that you trust Mt. Gox.)
Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc)
Uh-oh. Ruby on Rails has a lot of default settings that are decidedly not secure; our own Patio11 wrote an article on this topic for the CACM not too long ago.
You might want to sit down with a security professional before too long, and get an outside opinion on your code.
My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business.
Currently our only non-trivial security challenges are as follows:
- SQL Injection
- Source being viewed
- Financial attacks
I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord.
Heroku protects everything nicely. Even the filesystem is read-only. There's virtually no way to control the server provided Heroku's 3-layer architecture (Varnish, Nginx and Thin).
We don't operate a Bitcoin wallet. Basically hackers have nothing to steal. Even if we are totally owned, the most that hackers can do is to get some free money and make some trades. After all, we can obviously identify and not to approve withdrawals (for unusual and large-amount ones).
You should know that when you write comments like this, you communicate two (bad) things:
(i) You don't know enough about appsec to be communicating things about the trustworthiness of your application.
(ii) Any feedback you're given about the threats your application faces is just going to get added to your list of "security challenges" you are aware of or have tried to address, which implies that anything anyone does to help you with your security is just going to be used to mislead others. No thanks!
I'm thrilled at the idea of a 17 year old building applications that need serious security countermeasures and would generally love to help. But not when the stakes are "other people's money".
You should pick a different project. For a variety of reasons. How about take your Bitcoin exchange and do (another) play-money exchange, like for a prediction market?
Seconding Thomas' advice. You could even write against the API of one of the existing prediction markets (thus inheriting their user base) and try to add, e.g., options to it. That will give you plenty of holes to shoot in your foot without ever causing more damage than wiping out the geek cred of someone who tried to prop trade using the knowledge that there are unlikely to be two next US presidents.
P.S. I used to participate on a prediction market. Was winning the Internet after going all in on three presidential elections. Got wiped out by JPY breaking a hundred two years too late for my contracts to pay. Did not jump out window.
the most that hackers can do is to get some free money
That sounds pretty serious, and also a very laxidasial attitude to the security of money. You want me to give you some of my money?
People aren't worried with being hacked per se, we're not too concerned with if your server stays up, or if someone writes a temp file or if they make your heroku bill go really high. 'Security' in this case means my money and/or my bitcoins, which I'm entrusting to you. Can you make sure my money doesn't disappear? Statements like "well all that can happen is the money disappears" does not make me trust you.
All software has security vulnerbilities. Nothing in 100% secure. You need to know what your vulnerbilities are. You are entrusting your users to not reuse passwords, that's a vulnerbility. You should have a list written down (privately) of your vulnerbilities.
- Source being viewed
I assume you mean the Ruby on Rails source code of your application? That should not be a security mechanism. You should be able to put that online and let everyone look at it without that having any security implications.
There is more to security than hardening your code. For example, I assume you have some sort of master/root/admin level account on your own website. Are you using the same password as your email account? Do you use a third party email account? Do you have a 'forgot my password' feature? Here's an attack vector: I get read access to your gmail account, then I use the 'forgot my password' feature to change your password and I have then rooted your site.
From the web application & OS level everything is fine. No-one has compromised anything, the web application has performed exactly as required, since the admin user has just logged in normally.
There's also social engineering attacks, could I get you to open a certain webpage that I control? What will that tell me about your web browser? Does that give me control of your heroku server?
Well, being hacked allows such financial attacks, obviously (one direction: dump zillions of BTC into the market, pick them up really cheap; other direction: ask for zillions of BTC, sell them really expensively).
There is also account security (e.g. changing my default withdrawal account to something attacker-controlled), for instance. Password security (people re-use passwords...) And perhaps an attacker can withdraw money or BTC from your Mt Gox account?
This is BTC - security amateur hour - so you may well be better than, say, Mt. Gox. But if you get going, you should have someone competent looking at the code. (tptacek and co do that kind of stuff, but he's not exactly a BTC fan. Also, this kind of work is expensive.)
Those two examples are _exactly_ the same; it's clear you don't understand the actual problem.
With SQL, you must never, EVER mix untrusted data (ie, data from a user) with your trusted code (ie, SQL statements). The same applies to HTML - never, EVER mix untrusted data with trusted code (ie, HTML tags). If you want to mix the two, you must either:
a) first take steps to make your untrusted data trustworthy - for HTML, use an appropriate HTML scrubbing library to remove dangerous tags (or simply escape every & or <). For SQL, you'd have to escape all metacharacters - but I wouldn't recommend doing this for SQL, see below
b) Find a way to transfer the data separately. All modern SQL libraries allow you to specify named variables in your SQL code, then fill in the variables separately. With this, the SQL library takes care of separating the untrusted data and trusted code.
The mechanism used to combine code and data is not the problem - + and #{} are equally harmful if used improperly, and equally harmless if properly escaped .
I'm another voice recommending that you sit down with someone who works in security :)
For instance, right now what's to prevent someone brute-forcing login and password combinations?
Likewise, even if it is the user's fault for having lax password security, for something that involves direct money transfer, it'd be nice if you could send a warning or block an account if it's accessed from, say, Russia when it's always previously been accessed from the States.
Also, what if Heroku gets hacked, or has a undisclosed security hole, or someone bribes one of their employees? You can't protect against everything, but what can you do to minimize the risk?
To add to mootothemax's post, non-repudiation is often important in financial systems. This is the ability, if a user comes to you and says "It wasn't me that made these transactions, so they're invalid," that you have the ability to argue whether they did or did not make those transactions. At a minimum, this probably means logging IPs like mootothemax suggests.
Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox).
Sounds like you've outsourced security to a website (Mt. Gox) that has a proven track record of being stupid with security. That does not reflect well on you.
I think he's outsourced security to a site that has experience in dealing with security and has (hopefully) learned something from their mistakes. For bootstrapping, I'd say it's acceptable.
When did you start working on this project and have the negative events (guy losing 500K, MtGox hacking, etc) of the last few months affected your development and outlook?
I only started working a week ago. I'm currently in school holiday, so I can afford long hours. And since this is a solo project, I have no communication problems. I can just do what I have planned and thought.
These negative events are actually quite normal. Actually they present us with all kinds of problems. Every entrepreneur's task is to solve problems. And now we have more problems to solve.
Being optimistic,
Positive events == opportunities
Negative events == opportunities (for those who are smart)
You can look through some of my comments here. I have explained how I solve the security problem.
Yes, I'm using Twitter Bootstrap. It's very easy to get started for a non-designer like me.
Looks pretty cool. I dislike the random pink highlighting, it's noisy. Avoid smiles, as cool as it is, you must look professional in business ;)
That said, maybe a security section would be great. eg encryption, security, independent audits, etc. Here's an example: http://help.github.com/security/
That's a great site and will help people that haven't got any trading experience to 'play' a little bit without having to do all sorts of things in the 'real' money market
A little feedback:
Tooltip texts for some of the interface elements would be nice. I had to think a bit before figuring out that "P/L ($)" is supposed to be profit/loss.
Deleting a session cookie is not the same as a logout button, because the session needs to be terminated server-sided as well, otherwise it is still active and anyone with access to the session ID could restore the session (until the natural session timeout occurs - which entirely depends on the server's configuration).
I'm the creator of Bitcoinica. I'm not so established here. To be honest, I'm only 17.
Please try it out. (I can pay $1 for you if you're not willing/able to deposit, email me at info@bitcoinica.com. :-D ) You can leave any suggestions, comments, bug reports and feature requests here. I'll look through every single comment. Thanks!