Bitcoin Forum
December 17, 2017, 01:59:15 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: New LTC exchange concept  (Read 1366 times)
daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
July 31, 2012, 02:37:17 PM
 #1

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

1513519155
Hero Member
*
Offline Offline

Posts: 1513519155

View Profile Personal Message (Offline)

Ignore
1513519155
Reply with quote  #2

1513519155
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513519155
Hero Member
*
Offline Offline

Posts: 1513519155

View Profile Personal Message (Offline)

Ignore
1513519155
Reply with quote  #2

1513519155
Report to moderator
VelvetLeaf
Member
**
Offline Offline

Activity: 98


View Profile
July 31, 2012, 02:49:21 PM
 #2

You should use salt to make it more secure

BTC : 1GN81dxzxyFPQsyAtdocXr5S9Mcg4wcfFG
LTC : LgmYvXsYXc4xdjsMKXJWqtagxVvioK6iaw
FC : 6dpSnKMtttUUYzaRu1EB7Lu18PBRVHU3V7
tgsrge
Member
**
Offline Offline

Activity: 70



View Profile
July 31, 2012, 02:54:22 PM
 #3

i dont understand what you are trying to achieve with this Huh
daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
July 31, 2012, 02:59:24 PM
 #4

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.

Stephen Gornick
Legendary
*
Offline Offline

Activity: 2338


✪ NEXCHANGE | BTC, LTC, ETH & DOGE ✪


View Profile
July 31, 2012, 05:37:51 PM
 #5

  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.

daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
July 31, 2012, 08:14:57 PM
 #6

Thanks a lot for you suggestions!

Buffer Overflow
Legendary
*
Offline Offline

Activity: 1652



View Profile
July 31, 2012, 08:47:59 PM
 #7

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.

burnside
Legendary
*
Offline Offline

Activity: 1008



View Profile WWW
July 31, 2012, 09:13:53 PM
 #8

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.  Smiley


I'm not a Coinbase fan -- I placed a buy order, they took the funds out of my account, then a week later the price went up and they canceled the buy and closed my account.  You've been warned.  Use a different exchange.
daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
July 31, 2012, 09:40:26 PM
 #9

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.

Buffer Overflow
Legendary
*
Offline Offline

Activity: 1652



View Profile
August 01, 2012, 09:08:53 AM
 #10

You should be using 'innodb' databases instead of the older 'myisam'. These have the benefits of foreign keys and transactions.

daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
August 01, 2012, 10:50:57 AM
 #11

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.

iddo
Sr. Member
****
Offline Offline

Activity: 360


View Profile
August 01, 2012, 12:36:25 PM
 #12

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.

Just curious, why bcrypt and not scrypt? Have you read the scrypt article/slides?
Buffer Overflow
Legendary
*
Offline Offline

Activity: 1652



View Profile
August 01, 2012, 02:27:59 PM
 #13

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?

iddo
Sr. Member
****
Offline Offline

Activity: 360


View Profile
August 01, 2012, 06:49:30 PM
 #14

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
Buffer Overflow
Legendary
*
Offline Offline

Activity: 1652



View Profile
August 01, 2012, 08:18:56 PM
 #15

Nope, never used Litecoin yet. Only Bitcoin.

iddo
Sr. Member
****
Offline Offline

Activity: 360


View Profile
August 01, 2012, 10:22:44 PM
 #16

OK cool, anyhow for bcrypt/scrypt comparison see for example the chart near the end of scrypt-slides.pdf
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!