Why do talking constantly to obtain the wallet to find subsequent prevent, this is actually the 3rd day and also the pocket book is not ready, this is one of the cause I get free from Antshares project at first since it is really frustrating to use their wallet and now almost thesame issue
Sorry I couldn't get what you mean. Could you please explain again? What is frustrating you? |
|
|
|
bisq v0.6.0 has just been released and now supports XCN: https://forum.bisq.io/t/new-version-0-6-0-released/3446It's the first true decentralized P2P exchange. I like it a lot, especially because you keep full control over your coins (always stay in your own wallet). I think this will be a great way for us to trade FIAT -> BTC -> XCN and back. And it supports some new TOR features to now make it work in China -> our favorite market  |
|
|
|
blockchain explorer not working for address balance.
What is correct total number of coins in circulation?
Ah sorry, I'm still reparsing all transactions, had done a small change to the domain setup recently. Here is the number you're looking for: 367664707.675039 Explorer is now back in sync. Thanks for response. Does this circulation include the coins generated due to recent bug that was fixed in the blockchain? That Pallas would have to answer as I was not involved in that and honestly don't know. |
|
|
|
Btw, looking at the explorer's connected peers: There are still quite a few wallets running the old protocol version 10100 out there. Everybody please update to the latest wallet version. It contains some important network improvement fixes. |
|
|
|
blockchain explorer not working for address balance.
What is correct total number of coins in circulation?
Ah sorry, I'm still reparsing all transactions, had done a small change to the domain setup recently. Here is the number you're looking for: 367664707.675039 Explorer is now back in sync. |
|
|
|
Coinmarketcap added AEX exchange after my request, so we jumped to around position 400 ;-)
Nice! |
|
|
|
Niiice, this already proofs what sort of volume this coin generates (0.65BTC last 24h). Time for me to finally get some BTC to start trading |
|
|
|
|
Wow, if you think about it, how crazy that exchanges not only take money to list a coin but also make lots of profits during trading.
Maybe some of the exchanges can be convinced to let us in for cheap if we point out our trade history on BTC38?
|
|
|
|
I really don't get it, Coinsmarket is listing like every coin out there why aren't we applying there?
What do you mean by "coinsmarket"? Maybe he's referring to this ? No. This is what he is talking about - https://coinsmarkets.com/The exchange which is 9 decimal places, so don't get confused about the pricing you see there. #crysx Is it a good exchange? Any experience? I honestly can't comment. It seems to be used, though it is a smaller volume, and people don;t seem to worry so much that it it trading with higher capacity of fractions of BTC, so assuming it is ok. I have personally not traded on it, so it would be incorrect of me to comment more than what I have. we at CWI prefer Cryptopia, for most of the coins we have, and about to push/pay for our last two coins to go on there, as we trade reasonably well there and are about to initiate the trading bot for the CWI-Mining system to plug into. So Cryptopia is what we have experience with and can say that it's API and systems are reasonably fast (not as fast as Bittrex though), and the support is good also. Forget Bittrex, unless they WANT you in their system. NovaExchange is reasonable, but are shutting down, whereas coinexchange.io seems to be running ok also, though it too (like CoinsMarkets) is a low volume Exchange. So there are a few choices, but I would think Cryptopia would be the better option, even if more expensive. Our experience with CCEX is not a pleasant one (we have DRZ there) due to the fact that continue (almost EVERY month) to place DRZ on the delist, and seem to be doing this with a LOT of coins to kick in the volume. So be wary of CCEX and their tactics, though it is a nice interface. Stay WELL away from yobit. You will suffer at their hands. Hope this helps pallas! #crysx Thanks for your comments :-) Let me add some. Cryptopia is expensive, but so is coinexchange and livecoin (about same price, too much for us). Yobit: we paid for inclusion, they did nothing, we got our money back. At least it's fair. Support is non-existent. We are going to be included in the next bisq update, but I have no idea of the volume it might bring as I don't have experience with distributed exchanges. Having to install an application to trade will probably scare some, but the concept is interesting and I like to think that it will be the future. The volume on bisq is super low, even for BTC <-> FIAT trades. But I think it's good to be in there early so we're available once they gain traction. I like the concept and I think it's the future (no man in the middle). I think Cryptopia sounds interesting then |
|
|
|
I really don't get it, Coinsmarket is listing like every coin out there why aren't we applying there?
What do you mean by "coinsmarket"? Maybe he's referring to this ? |
|
|
|
I believe it does that already. Don't think the limit is changeable though. It will reach at least one week into the past ( http://cryptonite.info/wiki/index.php?title=Cycle_time). I've seen my wallets keep them for longer. You can add -txindex 1 to keep blocks forever and turn your wallet into a "master" node. |
|
|
|
In short: blockchain is only needed to list old transaction details. If you're not interested in that, you can prune the blocks. The only thing that's not pruneable are the block headers (very small) which sign the highest block and the current account db state. After a very long time, even the headers could be pruned because they only function as a history of spent work: http://cryptonite.info/wiki/index.php?title=Proof_chainThat's the great thing about the mini blockchain. Finally something really scalable is around thanks to the Single Responsibiliy Principle in action (hello fellow programmers!) Btw, I've just done a full node re-sync from scratch in under 20 minutes from LAN. That's with complete transaction history. CPU load was <70% per core (<20% 4core). Simply awesome! Another thing about us going forward: I'd like to see some GUI additions happen in the wallet. There are still some core features of the coin which aren't usable in GUI, like: - change withdrawal limits - multi-sig transaction Especially the latter would be important because once that's easy & running, it would open up our path to become a base currency in the new BISQ exchange (trade FIAT <-> XCN directly). maybe we can set up a bounty for it? All required knowledge is in the wiki. |
|
|
|
any news from bisq?
Nope, nothing new here but I'm pretty confident we are going to be part of the next release. The current development build already contains XCN, so it's only a matter of waiting for the next official release. If we want to, we can already start trading by using the development build. I have confirmation from the main developer that that will not break the system. Only people with dev build will be able to see and understand our trade offers though. |
|
|
|
About the eps:
I don't really see a difference in the two approaches.
1) Autodetect incoming requests and offer two different reply messages, one with EP, one without.
2) Have a switch to set the system up - ok but why can't we smart-parse requests in this scenario as well? Then it would all be down to how we make the decision on the reply format. And there it doesn't really matter anymore whether we change the format based on a parameter or have a second message with the EP format. Bot options mean there's additional work for the receiving end required.
We could even combine both options like so:
- Autodetect incoming requests (EP / nonEP style)
- have a primary and a secondary reply
- make a parameter decide which of the two is EP and which is compatible
That way, the implementer (e.g. exchange coder) would have all options available, no matter what he prefers to do. He can either parse a different RPC response message OR start the daemon with a different set of parameters.
as i understand, it is an option for the exchanges. in such a way they can choose that option, that is correct to this exchange. so, we`ll need not to send various versions to different exchanges. Well, that's exactly what I was talking about, too. I might have done a bad job with wording. I'm just saying: Make the daemon as smart as possible, auto-handle as much/many cases as possible, present the most flexible options for manual customization/compatibility. |
|
|
|
|
About the eps:
I don't really see a difference in the two approaches.
1) Autodetect incoming requests and offer two different reply messages, one with EP, one without.
2) Have a switch to set the system up - ok but why can't we smart-parse requests in this scenario as well? Then it would all be down to how we make the decision on the reply format. And there it doesn't really matter anymore whether we change the format based on a parameter or have a second message with the EP format. Bot options mean there's additional work for the receiving end required.
We could even combine both options like so:
- Autodetect incoming requests (EP / nonEP style)
- have a primary and a secondary reply
- make a parameter decide which of the two is EP and which is compatible
That way, the implementer (e.g. exchange coder) would have all options available, no matter what he prefers to do. He can either parse a different RPC response message OR start the daemon with a different set of parameters.
|
|
|
|
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 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. |
|
|
|
@ gnasirator I am very impressed by your efforts on behalf of this coin!  Best of luck to you in your attempts to get XCN accepted as a base coin at Bisq.  Thanks! But it wasn't too much work, to be honest. If you look at the github commit from my earlier post, it was mostly copy&paste of some other alt coin's validator code and adjusting to our needs. Understanding what's going on there is what took the longest. My motivation for all this is two-fold: 1. I want society to end up with fair, debt-free money (FIAT obviously isn't). And for that we need a similar coin to bitcoin, but truly scalable -> XCN. (Maybe with some more privacy features in the long run ...) 2. As XCN is my first crypto experience so far (I don't have any other coins), I'm hoping to make a little profit along the way by running a small miner (single gpu). |
|
|
|
Yes, especially as I think that we have a great candidate to become one of their base currencies. All we need for that is enough volume. That would surely boost us AND provide bisq with a great coin to handle lots and lots of txs. The combination seems ideal to me. We'll see where it goes. I for my part have been doing some advertising over there. I hope the chinese pick up on it as that's a confirmed target market for bisq. The devs are currently looking into ways to get around the GFW and it seems like there are some to adjust their TOR implementation to be able to do so. That would boost bisq a lot and if we are on board by then, it should boost us too given our history of popularity over there. here's a screenshot of the current bisq development build I just tested on my machine (as committed on github in official repo):   I think the next release is planned in about 2 weeks. I'll keep you all posted. Once it goes live, we should add bisq to our list of exchanges and also promote the new exchange so our trading activities can start to grow again. 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 just cloned the wallet and did another compile and got this:
"/usr/include/c++/5/bits/unique_ptr.h:49:28: note: declared here
template<typename> class auto_ptr;
^
CXX net.o
CXX noui.o
CXX rpcblockchain.o
CXX rpcmining.o
rpcmining.cpp: In function ‘json_spirit::Value getblocktemplate(const Array&, bool)’:
rpcmining.cpp:575:52: error: invalid use of incomplete type ‘class CWallet’
pblocktemplate = CreateNewBlock(pwalletMain->GetDefaultPubKey());
^
In file included from rpcmining.cpp:9:0:
init.h:11:7: note: forward declaration of ‘class CWallet’
class CWallet;
^
Makefile:882: recipe for target 'rpcmining.o' failed
make[3]: *** [rpcmining.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/xcn/Cryptonite/src'
Makefile:904: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/xcn/Cryptonite/src'
Makefile:676: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/xcn/Cryptonite/src'
Makefile:510: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
"
is something not working in there?
my .configure:
./configure CFLAGS="-O3 -march=native -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free" CXXFLAGS="-O3 -march=native -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free" CRYPTO_LIBS="-lcrypto -ltcmalloc" --without-gui --disable-wallet
|
|
|
|
|
Show Posts
