|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
mobile4ever
|
 |
July 20, 2012, 12:15:43 AM |
|
I took a look at it. How does that work? Is it downloaded to a computer and used from there? |
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 20, 2012, 08:02:53 AM |
|
I took a look at it. How does that work? Is it downloaded to a computer and used from there?
No, it must be installed on server by exchange owner... However, I plan that several people will be in charge of the operations. BTC will be deposited into multisignature transaction - making them impossible to steal ( yes! your BTC will be 100% safe from hackers). However it will impose some limitations - withdraws must be processed manually, let's say once a day. Exchange officers will have special scripts locally that connect to database and do quick validation of user account before withdraw. Making sure that exchange is not hacked. |
|
|
|
|
|
BitcoinBug
|
|
July 21, 2012, 08:10:42 AM |
|
Did not check the code, but I think you've made some very good decisions (NodeJS, multisig). I wish you good luck!
|
|
|
|
|
|
mobile4ever
|
|
July 22, 2012, 12:57:46 AM |
|
I took a look at it. How does that work? Is it downloaded to a computer and used from there?
No, it must be installed on server by exchange owner... However, I plan that several people will be in charge of the operations. BTC will be deposited into multisignature transaction - making them impossible to steal ( yes! your BTC will be 100% safe from hackers). However it will impose some limitations - withdraws must be processed manually, let's say once a day. Exchange officers will have special scripts locally that connect to database and do quick validation of user account before withdraw. Making sure that exchange is not hacked. Awesome... I am interested. What is the underlying language... (sorry for my stupidity) |
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 22, 2012, 07:34:36 AM |
|
Client side - http://backbonejs.orgServer side - http://nodejs.orgAll logic handled by http://www.postgresql.orgTrading engine is already done, now I need to do: a) API b) Web-interface for trading c) BTC deposit/withdraw module b) Fiat currency deposit/withdraw module Fiat currencies will be using "codes", like MTGOX has. I will encourage "codes" trading as much as possible, it will give liquidity boost to exchange. |
|
|
|
|
davout
Legendary
 Offline
Activity: 1372
Merit: 1007
1davout
|
|
July 22, 2012, 11:44:22 PM |
|
You don't plan on piggy-backing on another exchange for margin trading liquidity ?
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 23, 2012, 03:18:23 AM |
|
You don't plan on piggy-backing on another exchange for margin trading liquidity ?
What? I don't understand what you wrote here... |
|
|
|
|
|
|
|
EnergyVampire
|
|
July 23, 2012, 07:42:19 PM
Last edit: July 23, 2012, 08:50:17 PM by EnergyVampire |
|
Hello Andrew Vorobyov,
Automatic Database Backup: I'm not sure if this should be a feature but backing up data at regular intervals would be nice to prevent another Bitcoinica scenario.
Auditing Tools: Every transaction should be easy to audit for the operator, whether it is a trade, order update, funds transfer, etc. This might also reduce the burden for independent 3rd party auditing and transparency.
|
|
|
|
davout
Legendary
Offline
Activity: 1372
Merit: 1007
1davout
|
|
July 23, 2012, 08:40:48 PM |
|
You don't plan on piggy-backing on another exchange for margin trading liquidity ?
What? I don't understand what you wrote here... I'm wondering whether what you are coding is a standalone exchange, or an additional layer on top of existing exchanges. |
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 24, 2012, 03:22:47 PM |
|
Automatic Database Backup: I'm not sure if this should be a feature but backing up data at regular intervals would be nice to prevent another Bitcoinica scenario.
Sure, it will have incremental (daily, maybe hourly) backup + snapshot backup of current balances. Auditing Tools: Every transaction should be easy to audit for the operator, whether it is a trade, order update, funds transfer, etc. This might also reduce the burden for independent 3rd party auditing and transparency.
As for me, I would be ready to give read-only access to DB to auditor BUT: Data that auditor can access must be anonymized several levels deep. I don't want some customers emailing: "Fuck you and your transparency - now my neighborhood knows how much BTC I have". This must be addressed in FULL. |
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 24, 2012, 03:28:11 PM |
|
I'm wondering whether what you are coding is a standalone exchange, or an additional layer on top of existing exchanges.
It will be stand alone exchange. But you know what is http://en.wikipedia.org/wiki/Arbitrage. Of course there will be people doing it and I really encourage people to do it (rebates like on Bitfloor) |
|
|
|
|
|
mobile4ever
|
|
July 25, 2012, 05:08:31 PM |
|
now my neighborhood knows how much BTC I have". This must be addressed in FULL.
This sounds like it can be localized to a city or district? Is that true? |
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 25, 2012, 05:21:07 PM |
|
This sounds like it can be localized to a city or district? Is that true?
I was exaggerating... but nobody wants their financial info be public. No matter how reputable auditor is there is a chance that info will be dumped on the internet. After this point nobody cares about your "I'm so sorry". |
|
|
|
|
|
EnergyVampire
|
|
July 25, 2012, 05:53:41 PM |
|
For the auditing tools, I was assuming high ethical standards by auditors and the customers' private info isn't easily compromised.
It's more to:
1. Prevent situations like the Tradehill-Dwolla backdating mess (Why did Tradehill take months to look at their balance and compare numbers?).
2. Better customer service response time (because paper trails are king in this area).
3. Making SQL Injection attacks more difficult to carry out (it's possible many customer claims from the Bitcoinica fiasco are lies).
4. Help in eliminating FUD posts.
There's probably a 1,000 better reasons.
The exchange owners have good reason to follow CYA (Cover Your Ass), they are high value targets. Anything to help them out would be heaven sent imo.
|
|
|
|
|
Andrew Vorobyov (OP)
|
|
July 25, 2012, 06:02:48 PM |
|
I also expect these audits delayed.
For example, there is finance audit request by community. I pack data into zip archive with password and password is released only after 1-4 weeks. Otherwise, imagine situation:
There is one big account short on bitcoin - let's say 40K BTC. Everybody see it and trying to do short squeeze - pushing price higher to force liquidation.
|
|
|
|
|
|
EnergyVampire
|
|
July 25, 2012, 06:11:23 PM
Last edit: July 25, 2012, 06:53:54 PM by EnergyVampire |
|
I also expect these audits delayed.
For example, there is finance audit request by community. I pack data into zip archive with password and password is released only after 1-4 weeks. Otherwise, imagine situation:
There is one big account short on bitcoin - let's say 40K BTC. Everybody see it and trying to do short squeeze - pushing price higher to force liquidation.
LOL, I agree. It would suck to make that public info right away. A public "Short Interest" report once every 1-4 weeks without individual account identity is more than enough. Edit: Btw, community requested audits are more about the exchange itself and general operations rather than about their customers. Edit2: BTC-e's BitInstant Reserve balance clearly displayed on their website ( https://btc-e.com/) is a good example of some transparency which doesn't reveal customer info. |
|
|
|
|
