The whole "proof of stake" idea could have profound effects on exchanges too--0% trading fees, as they would make money from your coins just sitting in their account
On that note, would anyone be interested if I made an exchange that used text-based clients instead of a website? I would do it that way for two reasons:
1.) Security (no web fronted that can be abused, I find server-side code is much easier to secure, and I would do manual payouts to increase security perhaps...)
2.) Ease of creation (I find that making a program like that is much more simple than making a website).
It would be secure as there isn't a web front-end to attack, and perhaps I would even do payouts manually to increase security (aka server doesn't even have a link to the wallet, instead works on a store of maybe 10,000 addresses for each currency (Litecoins, Bitcoins, PPCoins)). Or is this just a crazy idea?
Web site is no different from any other client-server application. In fact, you can just implement a certain RPC API on a server (i.e. JSON-RPC or XML-RPC), and client software (HTML+JS) will be solely responsible for user interface. But with this design one can implement any other user interface, including command-line one.
So there is no difference.
The reason I was looking at a text-based (or console-based) application was to avoid the possibility of things such as mySQL injections (which I know are preventable) and similar attacks. Having an application that has certain mySQL commands hard-coded into it instead of leaving them open to the internet or based on the parsing of a URL seemed a safer route, but perhaps I am wrong.
No offense, but you're completely wrong. A web client is really no different from a command line one, especially as far as safe processing of user-generated data is concerned. Who cares whether the user typed the SQL injection into a web browser or into the command line? The effect is the same.
Safe validation of each and every bit of client-generated data (whether browser or command line client) that gets processed by the server is absolutely crucial. Just to name the two most obvious things: Watch out for negative numbers and prevent SQL injections by using parameterized prepared statements.
I used such a HTML+JS client + JSONRPC server approach like it was detailed above in MPBM and Bitcoin WebUI for a reason. It's easy to implement on the server side, has less possible attack vectors and allows for greatest flexibility. Bitcoin badly suffers from not having decoupled bitcoin-qt from bitcoind from the very beginning, and I'm sure it won't be long until they finally split that out, even though it will be a fair bit of work.
My logic with the command line option was that I know java far better than web development, so I'd be able to secure it a lot easier, but on second thought I really don't want to make an exchange, as I'd be the one in the end holding the bag when someone finds some security hole in my program. I'm not confident enough in my programming skills at this point in time to put money on the line like that... it just takes one oversight
Thanks for the input though, and yeah, the only reason the java client was more secure is because I could code it alot better.
