[ANN][XCN] Cryptonite - NEW Thread | 1st mini-blockchain coin | Bounties!

[pallas]

Hi,is it possible to solo mine? suprnova disconnect too often.
my conf is
" rpcuser=rpcuser
rpcpassword=rpcpass
rpcport=14443
listen=1
server=1"
after I started ccminer,It shows "No payout address provided,switchin to network",is it ok?
thanks.

Getwork, yes it's correct.

[krnlx]

Reducing CPU usage while accepting new block.

It is indeed a lot faster when accepting blocks, that's really what was needed, great! :-)
But it will need to be tested and hard limits removed.
Currently my test wallet hanged on trie sync, not necessarily related to the patch.

Trie sync issue is another problem, but I never seen it, when I force wallet to sync from one node (connect=xcn.suprnova.cc).

There is another bottleneck in wallet - to many malloc() (c++ new()) calls

I have one old trick from 2006, which seems stable, I am testing it now.

[teosanru]

Launch of Masternodecoin in approximately 23 hours, it is offering 1000 users the amount 52,000 coins to implement a masternode completely free, if certain requirements that can see in this thread are met
https://bitcointalk.org/index.php?topic=2056867.0

You can also win coins by keeping the currency signature on your profile,
By re-twiter

[krnlx]

GUIDE: Compiling xcn wallet with TCMALLOC allocator.

The fastest malloc we’ve seen; works particularly well with threads
and STL.

This fix eventual memory leaks and improve overal stability and performance.

1. Download and compile TCMALLOC

Code:

sudo apt-get install libunwind-dev
git clone https://github.com/gperftools/gperftools
cd gperftools/
./autogen.sh
./configure CFLAGS="-O3 -march=native" CXXFLAGS="-O3 -march=native" --prefix=/usr
make -j4
make install

2. Compile xcn wallet with TCMALLOC library

Code:

git clone https://github.com/pallas1/Cryptonite
cd Cryptonite
./autogen.sh
./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"
make -j4

Then check, that cryptonited linked with TCMALLOC :

Code:

ldd src/cryptonited

Code:

	linux-vdso.so.1 =>  (0x00007ffd6abe4000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6164a87000)
	libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007f6164883000)
	libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x00007f616466a000)
	libboost_program_options.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.58.0 (0x00007f61643ec000)
	libboost_thread.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0 (0x00007f61641c6000)
	libdb_cxx-4.8.so => /usr/lib/libdb_cxx-4.8.so (0x00007f6163e21000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f6163ba1000)
	libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f6163939000)
	libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007f61634ec000)
	libtcmalloc.so.4 => /usr/lib/libtcmalloc.so.4 (0x00007f61630f2000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6162d70000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6162a66000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6162850000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6162486000)
	/lib64/ld-linux-x86-64.so.2 (0x000056455c3f5000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f616227d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6162079000)
	libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f6161e5d000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6161c3b000)

This string must exist :

Code:

libtcmalloc.so.4 => /usr/lib/libtcmalloc.so.4

I checked CPU usage of new allocator with valgrind:

[palgin]

0.1.3.0 built for Windows:

https://github.com/palginpav/Cryptonite/releases/tag/0.1.3.0

With latest pallas commits, krnlx patches not included (this time, need someone to test my build first) think I didn't forget to statically link somethng  

Qt wallet will be added later, setting up build environment for this is pure pain (at least for me).

Test if you want and report.

And everybody have a nice weekend!

[pallas]

GUIDE: Compiling xcn wallet with TCMALLOC allocator.

Thanks for this guide! I linked it on the first post, if you don't mind.

[pallas]

Reducing CPU usage while accepting new block.

It is indeed a lot faster when accepting blocks, that's really what was needed, great! :-)
But it will need to be tested and hard limits removed.
Currently my test wallet hanged on trie sync, not necessarily related to the patch.

Trie sync issue is another problem, but I never seen it, when I force wallet to sync from one node (connect=xcn.suprnova.cc).

Thanks, I will try this.
Maybe the faster AcceptBlock (which is actually a faster Activate), since it should speedup getslice as well, may make the trie sync issue much less common.
Thus, when the network is updated, it may go away by itself.

So people please test the krnlx patch to death, and also we need to set a much higher hard limit for block number or make it dynamic (without this we can't push the improvement to production).

[pallas]

0.1.3.0 built for Windows:

https://github.com/palginpav/Cryptonite/releases/tag/0.1.3.0

With latest pallas commits, krnlx patches not included (this time, need someone to test my build first) think I didn't forget to statically link somethng  

Qt wallet will be added later, setting up build environment for this is pure pain (at least for me).

Test if you want and report.

And everybody have a nice weekend!

Thanks for your build!
As soon as we get enough good reports, I will put it into the first post and notify btc38!

[nu1mlock]

0.1.3.0 built for Windows:

https://github.com/palginpav/Cryptonite/releases/tag/0.1.3.0

With latest pallas commits, krnlx patches not included (this time, need someone to test my build first) think I didn't forget to statically link somethng  

Qt wallet will be added later, setting up build environment for this is pure pain (at least for me).

This is greatly appreciated! If possible (unless bitfreak has responded to Pallas and said yes already), it'd be great if you could eventually compile the qt wallet as well. I use both cryptonited and qt. I use the qt wallet on my PC because it's easier to look through transactions etc with the GUI.

Regarding that, is it possible to use both the new cryptonited and old qt for the same wallet on different computers? As in, can I use the new cryptonited wallet on my rigs and the old qt wallet on my PC without messing anything up?

Edit: Also, will the new wallet have to connect to only other nodes with the same wallet version in the config file?

[palgin]

This is greatly appreciated! If possible (unless bitfreak has responded to Pallas and said yes already), it'd be great if you could eventually compile the qt wallet as well. I use both cryptonited and qt. I use the qt wallet on my PC because it's easier to look through transactions etc with the GUI.

Regarding that, is it possible to use both the new cryptonited and old qt for the same wallet on different computers? As in, can I use the new cryptonited wallet on my rigs and the old qt wallet on my PC without messing anything up?

Edit: Also, will the new wallet have to connect to only other nodes with the same wallet version in the config file?

Think it's safe, pallas avoided syncloop by limiting number of getslice from one peer, it shouldn't affect your local copy of chain and you're free to connect to any node (anyway, nodes with new wallet preferred)

Stuck with qt build, environment doesn't recognise half of static qt libs so can't compile qt bin, will investigate further. Some patches have already been needed because of newer dependant libs versions. As I see wallet is based on bitcoin-qt 0.9.x with modifications.

[krnlx]

Thanks, I will try this.
Maybe the faster AcceptBlock (which is actually a faster Activate), since it should speedup getslice as well, may make the trie sync issue much less common.
Thus, when the network is updated, it may go away by itself.

So people please test the krnlx patch to death, and also we need to set a much higher hard limit for block number or make it dynamic (without this we can't push the improvement to production).

A few words about my patch:

I. What is doing TrieView::Activate ?

We have two chains with blocks:

Code:

1,2,3,4,5,6,7,8,....,99,100,103,104

Code:

1,2,3,4,5,6,7,8,....,99,100,101,102,105

blocks get listed backwards (pindex->pprev) into two lists:

Code:

104,103,100,....3,2,1

Code:

105,102,101,....3,2,1

then same blocks removing from lists(starting from 1), we getting:

Code:

104,103

Code:

105,102,101

when we have a lot of blocks in chain, there is involved a lot of slow c++ boost staff (linked lists, memory allocs,etc)

II. What I've done?
1.allocated two arrays, and filled it with pointers to blocks.
2. Then scan them backwards until index reached SAFE_UNIQ or the blocks become different. So we get:

Code:

94,95,96,97,98,99,100,103,104

Code:

94,95,96,97,98,99,100,101,102,105

3. fill two linked lists with this blocks
4. then the original code works with those linked lists, which are short.

III.
I have never seen a situation where these two chains differ from each other by more than one block, but I did not rule out such an opportunity (for example 3 or more blocks in a row are orphan). If you rely on the fact that they will always differ by one block, then the code can be greatly simplified.

IV. Possible problems
1. Size for arrays: must be a bit more(number?), than block height. How correctly determine actual blockheight from TrieView::Activate?
2. Check my code for errors: it is small, but errors can exist : wrong indexes, which can cause illegal memory access, or incorrect results.

[Bilbo Bagacoins]

Trading and wallet back in action on Novaexchange.

[Sayman_nsk]

Trading and wallet back in action on Novaexchange.

yeeaaahh!! sell your mined coins for 100 sat`s

[teosanru]

Trading and wallet back in action on Novaexchange.

yeeaaahh!! sell your mined coins for 100 sat`s

Who will be the stupid that under the price of XCN in novaexchange selling to: 0.00000120, So it is better to focus on the reopening of trade in BTC38. That to have this type of exchanges, thus avoiding that stupid people have to under the price of the coin, it is my recommendation for you pallas, to recover the deposits and withdrawals in btc38

[Sayman_nsk]

Trading and wallet back in action on Novaexchange.

yeeaaahh!! sell your mined coins for 100 sat`s

Who will be the stupid that under the price of XCN in novaexchange selling to: 0.00000120, So it is better to focus on the reopening of trade in BTC38. That to have this type of exchanges, thus avoiding that stupid people have to under the price of the coin, it is my recommendation for you pallas, to recover the deposits and withdrawals in btc38

bter have 170 sat`s price...very close. this is just not a funny. coin is down in shit (sorry for my words)...btc38 not soon fixed wallet.

[palgin]

What's wrong? It seems pallas stated clearly:

As soon as we get enough good reports, I will put it into the first post and notify btc38!

Btc38 is running Windows-node, so it needs fix for Windows, which pallas added to 0.1.3.0 and I've compiled for Win. Just test and report, and btc38 will be back online in few days. 

P.S.: I've tested it during 34 hours, no issues for now.

[nu1mlock]

What's wrong? It seems pallas stated clearly:

As soon as we get enough good reports, I will put it into the first post and notify btc38!

Btc38 is running Windows-node, so it needs fix for Windows, which pallas added to 0.1.3.0 and I've compiled for Win. Just test and report, and btc38 will be back online in few days. 

P.S.: I've tested it during 34 hours, no issues for now.

Aren't they using the qt wallet though? So for btc38 to maybe get back up, the qt wallet needs to be compiled and tested first.

[teosanru]

What's wrong? It seems pallas stated clearly:

As soon as we get enough good reports, I will put it into the first post and notify btc38!

Btc38 is running Windows-node, so it needs fix for Windows, which pallas added to 0.1.3.0 and I've compiled for Win. Just test and report, and btc38 will be back online in few days. 

P.S.: I've tested it during 34 hours, no issues for now.

What a great news, the reopening of the wallet in btc38 is what is needed, not another exchange where stupid people lower the price of the coin

[antantti]

I tried syncing from scratch with an old laptop with hdd, was really surprised when it only took 32 minutes from start to synced and running.

Same old laptop with krlnx qt-wallet took 29 minutes to sync from scratch, cpu usage is down A LOT, it is not cpu limited anymore.

Also started testing with palgin compiled 1.3 windows wallets, we'll see where they go. Last two weeks without problems with wallets.

[gnasirator]

Trading and wallet back in action on Novaexchange.

yeeaaahh!! sell your mined coins for 100 sat`s

I don't see why that's a problem. After all, the indicated market price is dictated by the most recent trades. Just offer your XCN at a higher price and as soon as someone buys it, voila, the price on Nova updates. If no one buys it then the market price really is that low and you can buy XCN cheap and sell them expensive on BTC38. Either way, win