Topic: [ANN][XCN] Cryptonite - NEW Thread | 1st mini-blockchain coin | Bounties! - page 83. (Read 215666 times)

Novaexchange

It's new for me too, looks like they a trying to build some kind of multilingual exchange (including china, russia and tons of others) with fiat trading pairs too.

What really caught my eye was that bbr, it's in a way quite similar project to xcn, they lost their last exchange when bittrex kicked them out.

Bter is shutting down and bx.in.th is rather tricky to use and register. No other exchanges are currently available?

Never heard of this exchange before, is it good? Where from?

It might be worth it to ask Kucoin exchange if they would add xcn. I mean, they are going to list bbr...

just so that people don't think there is no way to trade XCN: we are actually listed on Novaexchange.

we have no exchanges, price is getting down. later it may rise. imho better keep it for exchanges now.

We've been delisted on BTC38 which was our primary market. Well, china was our primary market and you know how things went with exchanges there recently.
We are on novaexchange but the volume is too low, so we are trying to get the coin listed on some other exchange.

Hi guys. I have not come here for a long time.
Why the price so much fell down ?

Yobit didn't say it explicitly, but it's clear that they won't list XCN.
Luckly, we can have our 0.1 BTC back.
What to do with it?

1) buy XCN and put into the fund; price rises
2) keep for future exchange listings, or any other service we may need

I'd say 1).

it's true that the commandline option (or, better, conf option, or both) is less work for the exchange.
let's hear some more opinions then I'll start coding ;-)

situation number 1  your Exchange is new and never before add Cryptonite-
in your Exchange standard should call returns "balance": "10.12345678"
but Cryptonite return "balance" : "10.1234567800ep"
well your Exchange must convert this answer "balance": to "10.12345678" or to take "balance_dp" : "10.12345678"
for this (to take "balance_dp") the exchange will have to edit the exchange's code
 ::)I think the exchange will not agree to this

situation number 2  your Exchange is not new and have add Cryptonite before change
well your Exchange can converting this answer "balance": from "10.1234567800ep" to "10.12345678"
and Exchange will not have problems

situation number 3  your Exchange is not new and have add Cryptonite before change
but they still have problem witch converting "10.1234567800ep" to "10.12345678"
and they are not agree to change exchange's code especially for this coin....
well Exchange still have problems

if we are
add the -nonEP option
-nonEP = 0 return EP(default)
-nonEP = 1 return 53
-nonEP = 2 return 64
for situation number 1 your Exchange only need to change the daemon startup parameters(-nonEP = 1 return 53) and not to change exchange's code especially for this coin
for situation number 2 your Exchange have backwards-compatibility(-nonEP = 0 return EP(default) - return "balance" : "10.1234567800ep")
for situation number 3 your Exchange only need to change the daemon startup parameters(-nonEP = 1 return 53) and restart daemon and not to change exchange's code especially for this coin

future:

situation number 4  your Exchange is new and never before add Cryptonite and can work with full 2^64-
Exchange only need to change the daemon startup parameters(-nonEP = 2 return full 64) and not to change exchange's code especially for this coin

I like that and absolutely agree that this feature needs backwards-compatibility.
Any new feature usually does until the old way to do things becomes obsolete because everybody has moved on.

that's why I said it must be backward-compatible.

say an rpc call returns "balance":

"balance" : "10.1234567800ep"

we can simply add:

"balance_dp" : "10.12345678"

the old exchange will continue using "balance", the new one (not wanting to support EP) will just use "balance_dp".

on the RPC request parameters, we can detect the missing final "ep" and translate it to EP, so the rest of the wallet works as before.

pallas,
I think this option does not hurt, but you need to discuss with each exchange separately, because they may have already set up the parser EP

and, we can add the -nonEP option

I think so, even better would be, it is always easier to add a small parameter in the configuration file and have the desired result

if we return the amounts in two versions, they will have to build a separate parser

-nonEP = 0 return EP
-nonEP = 1 return 53
-nonEP = 2 return 64

Another idea could be to return both the EP and non-EP amounts; for the RPC requests, we could add support for both types. This way they won't need to change the config file, just look at the rpc response.

oooh swill here guys overdo it, implanted in the client that it was not worth it to implant ....   I think it was necessary at the outset to make 64to53.CLI expansion especially for exchanges and pools...

ps can we clean the code for today from the EP and to create a simple extension of the 64to53.CLI?

http://cryptonite.info/wiki/index.php?title=Coinbase_account

http://cryptonite.info/wiki/index.php?title=Cryptonite_API

can u may snapshot/backup? to have opportunity to come back if smth will be wrong? ok,we`ll lost mined for 3-5-7 days, but if it can help with exchanges - it is ok, i think