|
I had the xj 650 and it problems with the yics after standing for a while. I recall that yamaha offered some additive to put into the fuel tank to clean the system, because they had the same problem with new xj models. When they were shipped to the dealers, they were standing for a while, before they actually got sold, so the dealers had to use the cleaner to make the bike run properly.
|
|
|
|
|
Hmmh...what about legality of a trading platform in china? Might be interesting to have a collaboration just to avoid legal issues in other countries.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Thanks a lot for you suggestions!
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
java has this issue with Intersango here, too.
|
|
|
|
|
Evtl. solltest Du überlegen, Litecoins zu minen. Scheint mir auf Deiner Hardware sinnvoller zu sein.
|
|
|
|
|
Would still be very good. Maybe it's not too hard to read just the tickers. But tickers won't help you too much for trading, since you can't see the order volume...
Btw: when you read the btc-e.com ticker: buy and sell are mixed compared to MtGox. Pay attention to this...
|
|
|
|
|
Wow! If you can do this in an hour, you are really, really, good! I'm still working on a similar app, and it took me many weeks yet...
|
|
|
|
|
How many lines of Java, do you think, that is?
*I'm curious, since I like Java*
|
|
|
|
|
It seems to me, that 'buy' and 'sell' are mixed in the ticker? At least compared to mtgox? When I check the buy value, I get the lowest sell price it seems?
|
|
|
|
|
There is still a lot of room for improvement on the exchange side. The mtgox ui, the btc-e api, the withdrawal issues...
|
|
|
|
Sorry, I can't help you I guess, but you could be my long lost twin brother...  I have also 0 design skills and I'm also a fan of Lisp languages (I think Scheme is acually my alltime favorite). Just to be constructive: I came up with a solution for myself, namely a project that requires 0 design skills (trading app). You might consider a similar approach... |
|
|
|
|
I can code Java, but don't understand the Python code well, so I can't port it for you ...
|
|
|
|
|
I don't know, how to get around this, but I can tell you, that I also got 2 kinds of curl errors, when trying to get work. At the moment, I've setup solo mining.
Maybe there's a better pool for GPU mining?
|
|
|
|
|
Show Posts
