Bter is shutting down and bx.in.th is rather tricky to use and register. No other exchanges are currently available?
Novaexchange |
|
|
|
It might be worth it to ask Kucoin exchange if they would add xcn. I mean, they are going to list bbr...
Never heard of this exchange before, is it good? Where from? |
|
|
|
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).
we have no exchanges, price is getting down. later it may rise. imho better keep it for exchanges now. just so that people don't think there is no way to trade XCN: we are actually listed on Novaexchange. |
|
|
|
By having 0 reward on POS , it will discourage people to hold the coin. Then it will be dumped in the market and the price will spiral downward.
So that applies to all pow coins, including bitcoin :-) |
|
|
|
Hi guys. I have not come here for a long time.
Why the price so much fell down ?
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. |
|
|
|
|
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).
|
|
|
|
For those who grasp CUDA programming.
This CUDA project is running 256 threads per block , right?
If they were just 1 thread per block, would the result of the computation still be correct?
So 256 is just for performance or is also a requirement for ccminer to correctly do its job?
Thanks
you posted this on more threads and even on github, is it really so important and urgent? :-) there are many factors linked to TPB, not just performance. besides, why would you ever run a single thread per block? |
|
|
|
|
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 ;-)
|
|
|
|
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  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. |
|
|
|
I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.
Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces 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? 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. |
|
|
|
I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.
Give extended information about EP, at the moment during my experiments directly in the code I use uint64, and EP touches me only in the RPC or QT interfaces |
|
|
|
yes. if it was asic, that'd be 7 THs |
|
|
|
|
I wanted to share a discussion we had on slack recently.
It all started from the difficulty we are having of being listed on exchanges.
From an exchange integration point of view, Cryptonite is just like any other coin, except for the "extended precision" amounts.
Since they never tell us why xcn is not listed yet, we can't be sure that this is the problem, but it surely is something they must customize to support our coin.
What to do? Removing EP amounts and using standard 8 decimal numbers would make it downward incompatible, possibly breaking the services we already have, like nova exchange or the block explorer.
One possibility is adding a configuration option to disable extended precision amounts, so the exchanges can use the classic format, if they like.
It shouldn't be much work to do (developing such an option), BUT we must be sure that this doesn't bring any side effect.
Please share your opinions on the matter.
|
|
|
|
Hello Guys,
Does anyone know, what is minimum age of staking for Luxcoin?
Thanks and regards
Okane Satoshi
36h |
|
|
|
What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)
I don't know about telegram bots, but I guess it will have a lot of overhead compared to a standard, C based stratum implementation. Will it be able to verify and record tens of share submissions a second? Here it is said that a multithreaded connection is used between the client and the telegram server The application bot can be written and there are examples in c ++, for each unit mining you can have a separate dedicated connection to telegrams And how much does the average miner generate shares\sec in сryptonite? Depends on the stratum difficulty, which is set by the pool. |
|
|
|
What do you think about the idea of creating a bot telegrams as frontend mining pool? So that this bot could create accounts, keep statistics and give out tasks and take shares from miners. I'm thinking about creating a pool but I'm afraid that my server is bogged down by DDoS attacks, so came up with this idea (to cover a pool node of servers Telegram)
I don't know about telegram bots, but I guess it will have a lot of overhead compared to a standard, C based stratum implementation. Will it be able to verify and record tens of share submissions a second? |
|
|
|
Now something else:
What's going on with the explorer stats?
They read:
Coin supply: 364612601.651712 XCN
Unmined coins: 0.0000 XCN
Block Reward: 0.0000000000 XCN
Something is not right there.
I had a look at the coinbase account and it seems to be fine. Probably an issue with the php code of the explorer itself, will need to look into it. |
|
|
|
To earn POS, you need to have 16200 LUX on the account?
No, that's for masternode |
|
|
|
great! maybe it won't bring big volumes, but it's good to be on the bleeding edge of crypto development and decentralization! |
|
|
|
Network difficulty, the available pools. The perceived ASICs was Nicehash hashrate.
Curiously do you think that I said that Keccak can't be done on FPGAs very easily, because it seems as though that's what you think and I literally said the opposite of that a couple posts up. What I was talking about was Wolf0 talking out his ass. You guys cut out portions of the quote pyramid and then forget what I'm talking about then assume I took up a position where I said Keccak couldn't be done on FPGAs or ASICs, which is definitely untrue.
The part you're quoting was where I was pointing out that you were much more helpful in explaining why it could be done on FPGAs and Wolf0 just said 'I'm a developer it can be done!' and that was it..
That's what you do when you are out of trolling ideas for your argument: you blame someone else way of quoting messages. Now we know you probably will stop writing nonsense, at least for a little while. Hurray! |
|
|
|
|
Show Posts
