Topic: New LTC exchange concept (Read 1493 times)
OK cool, anyhow for bcrypt/scrypt comparison see for example the chart near the end of scrypt-slides.pdf
Nope, never used Litecoin yet. Only Bitcoin.
Just curious, why bcrypt and not scrypt? Have you read the scrypt article/slides?
No, can't say I've used scrypt. Is there any advantages over bcrypt? What's the best place to look for information on scrypt?
Dude... wake up... if you've used Litecoin then you've used scrypt, see:
https://github.com/litecoin-project/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
http://www.tarsnap.com/scrypt/scrypt-slides.pdf
Just curious, why bcrypt and not scrypt? Have you read the scrypt article/slides?
No, can't say I've used scrypt. Is there any advantages over bcrypt? What's the best place to look for information on scrypt?
Do not make the classic mistake of storing passwords using md5, sha1, sha256, sha512 etc. These are fast hashes, you need to use a slow hash.
Bcrypt is your best option. Bcrypt forces you to salt, and introduces a work factor, which allows you to determine how expensive the hash function will be.
Bcrypt is your best option. Bcrypt forces you to salt, and introduces a work factor, which allows you to determine how expensive the hash function will be.
Just curious, why bcrypt and not scrypt? Have you read the scrypt article/slides?
Maybe it shouldn't be mysql at all, but something that's easier to distribute and use. So the node owner just gets a single package and starts it.
You should be using 'innodb' databases instead of the older 'myisam'. These have the benefits of foreign keys and transactions.
Hmmh...some good points...
Ok, one thought about the security of the node. Maybe the security could be within the code of the node. The admin could just install and run it. So it should be possible to check from the outside, if the code works properly. This might be done via orders, that gets signed by the node and verified by the sender. Imagine a node doesn't know, if an order is a 'real' order or just a dummy to test the correctness of this answer. Think this might work?
Performance: yeah, that's a bigger problem. That's why I mentioned the permanent connections, so there are no TCP/IP connections established to send the data. Let's say a node keeps 10 permanent connections to other nodes. So in theory in might take 10 transfers, or so, to distribute an order across the network? You think, this would actually cause a delay, that keeps users from trading? Another option might be to add some delay until an order becomes 'visible' to the actual traders. So just add some 10s, or so, just to spread the message. When this delay is over, the nodes might display the info. To keep node hosters from cheating, there shouild be some encryption, or so.
Ok, one thought about the security of the node. Maybe the security could be within the code of the node. The admin could just install and run it. So it should be possible to check from the outside, if the code works properly. This might be done via orders, that gets signed by the node and verified by the sender. Imagine a node doesn't know, if an order is a 'real' order or just a dummy to test the correctness of this answer. Think this might work?
Performance: yeah, that's a bigger problem. That's why I mentioned the permanent connections, so there are no TCP/IP connections established to send the data. Let's say a node keeps 10 permanent connections to other nodes. So in theory in might take 10 transfers, or so, to distribute an order across the network? You think, this would actually cause a delay, that keeps users from trading? Another option might be to add some delay until an order becomes 'visible' to the actual traders. So just add some 10s, or so, just to spread the message. When this delay is over, the nodes might display the info. To keep node hosters from cheating, there shouild be some encryption, or so.
Forgive me but I'm not really sure how a decentralized exchange could work fundamentally.
With most online trading sites, you have some layer of protection if the other end does not make good on the trade. (ebay w/ paypal, amazon w/ cc chargebacks, etc.) But with coins even if you're just brokering the swap between two addresses there's no way to make the transaction safe because of the lag time in getting confirmed and because no matter how hard you try, someone has to go first. The transaction (confirmation) lag itself would be enough to keep most day traders out, they just need to be able to react to market conditions faster than such a system could support.
Central exchanges mitigate these effects by having pools of currency to draw from that essentially make the swap instant and trust is a main focus for them.
From a security standpoint, you'd have to place a lot of trust in whatever distributed system you build as well, and in each of the distributed nodes sysadmins abilities to keep their nodes secure.
I think the BTC-e guys did a pretty good job on this one. They seem to have limited the damage fairly well programmatically and while they could have better monitoring going that would alert them when things are out of wack, they did get it all fixed up pretty fast. I was thinking about spinning up an LTC exchange project last night too when I thought the BTC-e guys might not recover, but whomever takes it on, I hope they realize it's going to be a TON of work.
With most online trading sites, you have some layer of protection if the other end does not make good on the trade. (ebay w/ paypal, amazon w/ cc chargebacks, etc.) But with coins even if you're just brokering the swap between two addresses there's no way to make the transaction safe because of the lag time in getting confirmed and because no matter how hard you try, someone has to go first. The transaction (confirmation) lag itself would be enough to keep most day traders out, they just need to be able to react to market conditions faster than such a system could support.
Central exchanges mitigate these effects by having pools of currency to draw from that essentially make the swap instant and trust is a main focus for them.
From a security standpoint, you'd have to place a lot of trust in whatever distributed system you build as well, and in each of the distributed nodes sysadmins abilities to keep their nodes secure.
I think the BTC-e guys did a pretty good job on this one. They seem to have limited the damage fairly well programmatically and while they could have better monitoring going that would alert them when things are out of wack, they did get it all fixed up pretty fast. I was thinking about spinning up an LTC exchange project last night too when I thought the BTC-e guys might not recover, but whomever takes it on, I hope they realize it's going to be a TON of work.
Do not make the classic mistake of storing passwords using md5, sha1, sha256, sha512 etc. These are fast hashes, you need to use a slow hash.
Bcrypt is your best option. Bcrypt forces you to salt, and introduces a work factor, which allows you to determine how expensive the hash function will be.
Also, if you want to work distributed, best avoid 'auto_increment' fields. Use a UUID instead.
Bcrypt is your best option. Bcrypt forces you to salt, and introduces a work factor, which allows you to determine how expensive the hash function will be.
Also, if you want to work distributed, best avoid 'auto_increment' fields. Use a UUID instead.
Thanks a lot for you suggestions!
encrypted_password VARCHAR(40), -- encrypted password of the user
Please do not store encrypted passwords. Hash it with a salt and store that.
There are several open source exchange projects that might be a good starting point.
With the idea? Well, creating an exchange, that is harder to attack and therefore more secure...
With the posting here? I don't believe in the security through obscurity concept, so I think at least the protocol (and maybe a reference implementation) of such an exchange should be open. So I thought it might be a good idea to discuss problems (and hopefully solutions) that come with such a concept.
With the posting here? I don't believe in the security through obscurity concept, so I think at least the protocol (and maybe a reference implementation) of such an exchange should be open. So I thought it might be a good idea to discuss problems (and hopefully solutions) that come with such a concept.
i dont understand what you are trying to achieve with this 
You should use salt to make it more secure
Hi!
Will all the DDOS attack discussion lately and now the btc-e problem, we should discuss new ways of trading.
I thought about the minimal data for an exchange, and got these tables yet:
--
-- Table for the xchange users
--
DROP TABLE IF EXISTS users;
CREATE TABLE users (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of the user
nickname VARCHAR(40) NOT NULL, -- nick (or user-) name
encrypted_password VARCHAR(40), -- encrypted password of the user
email varchar(64) NOT NULL, -- email address of the user
language varchar(3), -- the prefered language id (us, de, etc)
timezone TINYINT(2) DEFAULT 0, -- the timzone the user is in (-12 to 12)
created TIMESTAMP NOT NULL DEFAULT NOW() -- date of the registration
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table users
--
--
-- Table for the funds of a user (for one currency)
--
DROP TABLE IF EXISTS funds;
CREATE TABLE funds (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of this fund
user_id INT NOT NULL, -- id of the user
currency TINYINT NOT NULL, -- id of the currency (btc, ltc, usd)
balance BIGINT NOT NULL, -- balance * 100000000
deposit_addr VARCHAR(32), -- If there was already a deposit addy generated, store it here.
last_updated TIMESTAMP NOT NULL DEFAULT NOW()
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table funds
--
--
-- Table for the xchange orders
--
DROP TABLE IF EXISTS orders;
CREATE TABLE orders (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of the order
user_id INT NOT NULL, -- id of the user
type TINYINT NOT NULL, -- 0 = buy, 1 = sell, 2 = deposit, 3 = withdraw
price BIGINT NOT NULL, -- The price as nano coins
amount BIGINT NOT NULL, -- The amount * 100000000
currency TINYINT NOT NULL,
payment_currency TINYINT NOT NULL,
parent_id INT, -- If this is a split order, this id points to the original order.
status TINYINT NOT NULL, -- 0 = created, 1 = processed etc.
created TIMESTAMP NOT NULL DEFAULT NOW(),
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table orders
--
It's written in MySQL, but it could be any other format. Important are just the data.
So I thought it should be important to organize the data in a network and not in single server, to make ddos attacks harder (don't want to claim impossible here). So those data should be distribute (and most obviously duplicated) over a network. Each node would become part of the exchange.
But there are problems. One, that I see, is performance. Orders should be spread quickly throughout the net, so everyone has an (almost) equal chance to react. I guess, that would mean socket connections between the nodes. Not sure, if that's even enough to spread the order fast enough.
Another issue are FIAT deposits and withdraws. I don't know yet, how to organize it, since every node would have to keep some share of the funds and would have to be accoutable for a withdrawal. Hard (or impossible?) to implement.
Implementation: I thought it would be good to build the data transfer on HTTP protocol. Maybe just via ajax calls. Would allow any user to access the exchange via a browser. To become a node, someone would have to install some exchange script. This version would mean, that there are nodes and simple users. Maybe it would be better to write a specific client, so every user becomes an exchange node (like the bitcoin client structure).
What are your ideas and/or comments on the issue?
Ciao,
Andreas
Will all the DDOS attack discussion lately and now the btc-e problem, we should discuss new ways of trading.
I thought about the minimal data for an exchange, and got these tables yet:
--
-- Table for the xchange users
--
DROP TABLE IF EXISTS users;
CREATE TABLE users (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of the user
nickname VARCHAR(40) NOT NULL, -- nick (or user-) name
encrypted_password VARCHAR(40), -- encrypted password of the user
email varchar(64) NOT NULL, -- email address of the user
language varchar(3), -- the prefered language id (us, de, etc)
timezone TINYINT(2) DEFAULT 0, -- the timzone the user is in (-12 to 12)
created TIMESTAMP NOT NULL DEFAULT NOW() -- date of the registration
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table users
--
--
-- Table for the funds of a user (for one currency)
--
DROP TABLE IF EXISTS funds;
CREATE TABLE funds (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of this fund
user_id INT NOT NULL, -- id of the user
currency TINYINT NOT NULL, -- id of the currency (btc, ltc, usd)
balance BIGINT NOT NULL, -- balance * 100000000
deposit_addr VARCHAR(32), -- If there was already a deposit addy generated, store it here.
last_updated TIMESTAMP NOT NULL DEFAULT NOW()
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table funds
--
--
-- Table for the xchange orders
--
DROP TABLE IF EXISTS orders;
CREATE TABLE orders (
id INT NOT NULL AUTO_INCREMENT, -- The unique id of the order
user_id INT NOT NULL, -- id of the user
type TINYINT NOT NULL, -- 0 = buy, 1 = sell, 2 = deposit, 3 = withdraw
price BIGINT NOT NULL, -- The price as nano coins
amount BIGINT NOT NULL, -- The amount * 100000000
currency TINYINT NOT NULL,
payment_currency TINYINT NOT NULL,
parent_id INT, -- If this is a split order, this id points to the original order.
status TINYINT NOT NULL, -- 0 = created, 1 = processed etc.
created TIMESTAMP NOT NULL DEFAULT NOW(),
) TYPE=MyISAM AUTO_INCREMENT=1;
--
-- End table orders
--
It's written in MySQL, but it could be any other format. Important are just the data.
So I thought it should be important to organize the data in a network and not in single server, to make ddos attacks harder (don't want to claim impossible here). So those data should be distribute (and most obviously duplicated) over a network. Each node would become part of the exchange.
But there are problems. One, that I see, is performance. Orders should be spread quickly throughout the net, so everyone has an (almost) equal chance to react. I guess, that would mean socket connections between the nodes. Not sure, if that's even enough to spread the order fast enough.
Another issue are FIAT deposits and withdraws. I don't know yet, how to organize it, since every node would have to keep some share of the funds and would have to be accoutable for a withdrawal. Hard (or impossible?) to implement.
Implementation: I thought it would be good to build the data transfer on HTTP protocol. Maybe just via ajax calls. Would allow any user to access the exchange via a browser. To become a node, someone would have to install some exchange script. This version would mean, that there are nodes and simple users. Maybe it would be better to write a specific client, so every user becomes an exchange node (like the bitcoin client structure).
What are your ideas and/or comments on the issue?
Ciao,
Andreas
Jump to: