Somehow, I forgot to post bootstrap.dat links --

I order to import via bootstrap.dat, you must place the file within your client's data storage directory.

Windows default: %APPDATA%/Xencoin
*nix default: ~/.xencoin
OS-X default: ~/Library/Application Support/Xencoin

When the client is started, it will auto-detect bootstrap.dat and import the blockchain.

When I tested this on both client versions I have, it worked without issue - but the older 0.6.3.x clients are slow as sin on import - most likely from lack of optimizations on SSE/SCRYPT that newer clients have (among other issues). 

When import is complete, bootstrap.dat is renamed bootstrap.dat.old (or something to that effect) - it can then be deleted.

Files are stored at Mega, in two archive formats - 7Zip (windows) and a gzipped tarball (*nix/OS-X)

xencoin-bootstrap-20150322.7z: https://mega.co.nz/#!YIZE3LZA!qBn37YIpBSyMlJFb6ZOrY0ObnHGVK4TM01G1f-J-Fr4
xencoin-bootstrap-20150322.tar.gz: https://mega.co.nz/#!tI5jVAjC!9qDn_rSg1AcNFXS4iDA8sZrJxWSDLWSh2QxQ6frDAb4

I do what I can  

A small update on where things stand:

XencoinCommunity 0.6.3.4 is available - the makefiles may need adjustment off my repo - Windows builds are also downloadable there - click the "Releases" to find them.

Xencoin v0.8.7.3 (the development branch forked last year) has seen some activity and will be nearing availability for release as well.  I seem to have resolved some of the performance issues that users were seeing even with low 'worker loads', and I've ported over other updates that have come up since then.  I disabled any v2 block lock-ins on this client till after testing and consensus says it's time.

Bootstrap.dat files are available - I'll post links shortly - the bootstrap.dat import is slow as hell on the 0.6.x client branch - as well as the startup time and overhead from that client because it's lacking TONS of code changes that have happened upstream - but I'll maintain that branch until consensus moves us up to the 8.7.x branch (where we need to be) --

There are still issues with blockchain / network confusion - haven't quite figured out how I was hoping to address that just yet...

I'll bring the p2pool node back online eventually - just haven't gotten back to it with the updates I'm trying to get applied.

Repos:

XencoinCommunity 0.6.3.4 (https://github.com/thecarnie/XencoinCommunity)
Xencoin v0.8.7.3 (https://github.com/thecarnie/Xencoin) - TESTING/UNSTABLE/NOT FOR PRODUCTION
Both are accepting pull requests and code support --
Also available is the DNSSeeder code, p2pool code, and some other things - the bitpay/bitcore/insight repos are out of date - but it's a REALLY slick blockchain explorer when it runs right --

Working on a bootstrap.dat for the blockchain - should be ready in a few hours -- p2pool node will remain offline for the time being.

A checkpoint update for XencoinCommunity will be coming soon - we're back to having a collision with another alt-coin when the client runs - a checkpoint should solve this. Due to the fast blocktimes on this coin, along with the 'network confusion' issues brought on by lack of proper fork/clone by original source, I may have to start a rolling 'point' release schedule for this client (0.6.3.4 is current - 0.6.3.x <-- x being the point updates for checkpoints) - this may help alleviate the 'stuck downloading wrong chain' issues I'm starting to see again in these older litecoin-clone-based clients. Depending on how often this is needed will determine the 'schedule' - but it's looking like about 2-4 weeks per point release for the blockchain.

To anyone who has started using the latest release, please be sure to note any issues/problems/successes with this fork.  I can't fix things or attempt to improve things if I don't know what's wrong or what's happening. 

A new thread is coming soon as well - once I get some more things organized.  Community members who can contribute, please get setup on Github if you aren't already for issue tracking and code submission/pull requests.  Thanks!

Primary supernode xencoin.liquidbbs.org is back online.  I'll deal with the p2pool sometime tomorrow...

The p2pool at http://xencoin.liquidbbs.org:24335 will be offline for a few hours while I move the supernode daemon over to the just-released version.
The supernode will also exhibit unstable connectivity during this time.
The DNSseeder will remain online while I get the other release built and the blockchain imported.  

I apologize for the inconvenience.

I have tagged and set a "release" of the updates applied.  

Win32 static binaries are available at the link below.  
There is also a download available of the GUI that tries to link to existing .dlls in on for Windows systems.  

Build Environment Used:
Linux jessie 3.16.0-4-586 #1 Debian 3.16.7-ckt7-1 (2015-03-01) i686 GNU/Linux
i686-w64-mingw32-gcc v4.9.1 (GCC)
OpenSSL v1.0.1m
Boost v1.53
QT v4.8.6
BerkeleyDB v4.8.30.NC
miniupnpc v1.9.20150206
libpng v1.6.16
libqrencode v2014.09.23
zlib-1.2.8

BACKUP YOUR WALLET.  I AM NOT RESPONSIBLE FOR WALLET ISSUES.  

I've tested this with blockchain download and transferring coins back and forth between the old v0.6.3.3 client, and the v0.8.7.3 build that's running on my seed node.  I have not performed any mining tests through this build.  

BACKUP BEFORE UPGRADING.  I CANNOT STRESS THIS ENOUGH... YOU NEVER KNOW WHAT MAY HAPPEN...

https://github.com/thecarnie/XencoinCommunity/releases/tag/v0.6.3.4

Additional Notes:
No Mac/OSX tests have been performed (a volunteer will have to verify the build process and produce clients - I will add them to the repo when available)
No building on Windows via Mingw-w64 have been tested.  This is a cross-compile build from a Linux box. 

There may need to be adjustments to the makefiles for platform builds.

If you have fixes, please submit a pull request.  I don't have millions of hours to support builds - nor financial resources to keep the seed node going indefinitely - but I will contribute whatever I can for as long as I can.

Small delay:

In a nutshell, with the surprise issues of OpenSSL being able to cause consensus issues in a *coin daemon (search posts by Gregory Maxwell and other BTC devs regarding this), I am holding back the updated Xencoin release (v0.6.3.4) builds I have for a couple days so that I can re-build with the newest OpenSSL libs available. 

It seems kind of pointless to me to release then have to make an additional release in a week to handle the OpenSSL updates. 

My builds of the wallet/daemon/node are all static builds (based on research and recommendations of BTC developers within how they manage builds) so that 'linked libraries can't surprise us with consensus issues' like they did to almost every other *coin out here.  My opinion follows that of the BTC devs on the issue of using static binaries in order to avoid surprises brought on by OS updates and the likes.

Additional to that, I will also make a second point release available directly after the first.  The ONLY change between the two will be that 0.6.3.5 will resolve the issue of a monolithic blockchain database on the local machine the client runs on and convert it to a segmented chain split across several files (as the new clients do). 

I will also create a bootstrap.dat for the blockchain and make it available as well for quick syncing new clients and users.  Our blockchain is right around a gig right now - which as a torrent could be downloaded in a matter of minutes rather than hours via the daemon.  If someone has a nice torrent seeder available to host it, please let me know and we'll work out getting it hosted. 

Sorry for the delayed upload on 0.6.3.4 but I just don't feel the need to release, then re-release binaries within a week of eachother...

It's no problem!  I don't have the time to offer to the coin that I initially promised several months ago - things just have gone downhill in my world - but this should help things "a little".

The coin itself still has problems - and future updates are jeopardized by the missing 'steps' taken by the original dev when the coin was designed (copied) from another alt-coin.  Had those steps been properly completed - we could be MUCH further along in upgrading things to the current master branches from the Bitcoin and Litecoin dev trees.  As I can dedicate more time to this effort, there may be some things that can be done - but I haven't had the time to research them much further.  For the time being, they will keep things going as they are for the coin and chain - and hopefully will help get it back on another exchange so there's some more action. 

When the testing completes, I will be downgrading the xencoin.liquidbbs.org seednode back to this version in order to help maintain consensus with the online clients.  My version running on the seednode has MANY updates to the core code that brings it up to date with the two main dev trees, but again, without fixes to this coin in general those updates are pointless and could possibly create a consensus issue...  More to come when I can get caught up.  In the meantime - I'll finish testing and get these builds online for anyone who's interested.

I will most likely start a fresh thread on it all, considering at this time it seems the "community" has decidedly taken over development and furthering of the coin - so I think we need a new thread as well...

I now have functional xencoind.exe (CLI) (static/static-linked/static-debug/static-linked-debug versions) as well as a xencoin-qt.exe (GUI) versions built.  One change I did not apply either is the update that splits the blockchain downloads into seperate 'size limited' files - which does speed up startup quite a bit.  But by leaving the current blockchain data configuration intact in this version, a new chain download should not be required.



I'm doing some final testing on things to verify stability and proper operation (as best I can), then will finalize the build settings for a full build of both that can be signed/hashed and published for download.  The source will also compile into linux clients, and should work for OSX clients as well (but again, I am unable to test or build ANY OSX clients at this time.

When testing is complete and I can reproduce the builds in a documented fashion, I will make available the client downloads, as well as tag the source for those in my GIT repo for this version.

There are still some MAJOR issues that need to be addressed before any "development" and "advancement" can move forward. 

These builds I am producing (and the updated source code) are simply a 'minor update' for checkpoints in the blockchain, to patch OpenSSL issues (old client uses VERY old SSL version that is vulnerable to several attacks), as well as update the source to compensate for the newer OpenSSL versions that tightened the ECDSA handlers (in a nutshell) and can cause consensus forks in the blockchain.  The discovery and subsequent alert that made it to Bitcoin and Litecoin via Gregory Maxwell (BTC developer) regarding the OpenSSL issues never was brought up here, but this client is definitely susceptible to those issues.  As such, I incorporated the patches into these builds from BTC (and LTC). 

Users are advised that if their systems have updated and they are linking dynamically to their OpenSSL libraries, that they can and will cause consensus forks in the chain due to the new OpenSSL verifications.    This codebase will take care of that.

It will also contain several changes to the build files to hopefully make it a little more straightforward to build.

Compiled CLI and GUI client/wallets based on v0.6.3.3 codebase + OpenSSL 1.0.1k(and later) consensus fork issue from ECDSA changes + updated checkpoints and seednode/DNSSeed will be forthcoming soon. 

The CLI is built and works, although if not properly shutdown via RPCserver command will cause exception at this time.  GUI client is in build and test at this time.

The EXEs will be available either on my github repo or via my web server I'm using for XNC related work.  Build instructions to replicate my builds will take a couple more days.

These builds are cross-compiled on a vanilla Debian Jessie VM using MinGW-64, but are compiled in x86 mode.  x86_64 builds will be sometime later after other issues are resolved and I can get time.

These are built using Berkeley DB 4.8.30, Boost 1.53, and QT v4.8.6-OpenSource.  They support UPNP but not IPv6 - I don't have the time to sort out the IPv6 issues for Windows builds - IPv6 should be fully functional for *nix builds.  The older libraries were kept for backwards compatibility with old wallets.

I don't own a Mac or any OSX products, so no testing or build support is available for those.  My repo is public should someone wish to build those. 

I will set a tag on the fork for this project when the GUI and CLI versions are all available for download so that the matching source will be available to reproduce builds.

Sorry for the delays, but within the next day or so I should have this available for everyone.

The only difference between the 0.6.3.3 and the 0.9.1.5 versions is different (additional checkpoints), and updated seed-nodes in the blockchain client - there are no other changes or fixes ported into it --

Apologies, as I had thought that there was a compiled EXE in that download.

Over the weekend, I will take TripTech's source and cross-compile it on my Debian-Jessie VM and make them available.   

Because of the orphan TX issue that shows up due to Xencoin sharing network identifiers (and blockchain identifiers) with Litecoin and a several other alt-coins, my updates continually run out of orphan tx memory-mapping space.  This causes communications failures in my updated code until the daemon is restarted.  I believe this is also causing CPU exhaustion in the end when miners are attached to a client due to trying to wrap orphan transactions into a block on a chain that they don't belong in - then self-rejecting them for valid getwork on a new block.

Until XNC can be separated away from LTC and the other coins (I think WorldCoin is in there too) - memory pool will not work properly, which basically locks us into older client versions that don't have many of the improvements we need to help stabilize and improve things...

I'll migrate copies of the original binaries over to one of my servers and make them available -- but the original repo is at GitHub - don't recall if the binaries are there as well.

I'll also host a copy of the two new clients at some point - once I get caught up --

The link el_Nickio posted has a compiled binary inside the ZIP file --

I have not made any binaries available of my updates - the source is available on Github (https://github.com/thecarnie ...

Another member has updated the original client with new checkpoints and has it available here as a zip - inside is a compiled windows client...

You can addnode=xencoin.liquidbbs.org as a node as well -

If I can free up some time, I'm hoping to work on updates more as well as a combined effort on a site and new domain...  But I'm not going to do any more updates till we reach a consensus on the direction of fixes -- because there are serious issues with upgradability of the client due to missed steps in the 'beginning' before we were involved...

I just checked the DNS seed and there's only about a total of 8 XNC clients out there that are live and 'reachable' - 1 is the seed-node, 2 are the other (updated) client - and the rest are older clients --

54.191.173.227 = xencoin.liquidbbs.org (seed-node) - not sure who the 46.x is -- the version number shows it's a newer client tho (not mine)
I've seen several of the old client out there -- because of the updates to the core in my client, the protocol version is higher, and I think my node doesn't connect to older clients unless it can't find newer ones (it seems) --

As for a fork, it wouldn't be a big issue so long as the clients were buildable and available -- and we set the fork block far enough out -- the problem I'm seeing though is that a fork wouldn't fix it.  It would require a different change - I'll try to document everything in a PM at some point.  I may take and see about making a different change and go from there --

So you're still seeing hardware errors on the GPU mining with AMD/ATI?  I saw a steady slew of blocks coming through! 

I've found what I think to be the ultimate issue with the version of the client I was working on (with high CPU and other issues) - but I have to make some changes and build on a testnet to know for sure -- but in the end - if it is the issue - there is two options - one is to roll back to the old client and only bring in a couple updates (which won't truly fix the problem it will just make things more stable) - the other is through a hard fork - if it's even possible - that's what I'm looking at now) - but because this coin shares network ID with several other coins - the crosstalk is causing problems for the new client I am working on...

CPU mined a block on the pool earlier -- it's the only v2 block in the chain --

http://xnc.se4.biz/block_crawler.php?block_hash=b1f78a176832c4305a9f4d4abc160bd6a6eef306351f39c9e01b1fc167855538

If you get a chance, give that another try -- I followed a couple bug reports thru GIT and I got my CPUminer to act right - so that should solve the GPU miner from having hardware errors...  (was getting same issues with CPUminer you were having with ATI/AMD (OpenCL) miner) - maybe this will work.  Just set any XNC address for payout - it's running on my 8.7.1 xencoind - so it should payout - so long as it wins some blocks - or I'll have to sort something out for ya for your time - I don't have any big mining hardware and so I don't generate coins anymore --

If this fixes the issue with OpenCL miners, then I'll update the GIT with the p2pool code -- then some more p2pool nodes can go online.  I won't be compiling a windows binary though - not anytime soon anyways...