[ANN][XNC] XenCoin | Instant | Stable | Long term Support - New UPDATE!!!

[thecarnie]

I have the xenseed running on seed.hasher.ca now....

You still running this?

Since the main seed node is down (domain gone), if a couple stable ones existed, they can be added to the source.  I don't have that source repo anymore -- if you still have a copy, let me know -- I'll re-post it on github --

[thecarnie]

I have the xenseed running on seed.hasher.ca now....

You still running this?

Since the main seed node is down (domain gone), if a couple stable ones existed, they can be added to the source. I don't have that source repo anymore -- if you still have a copy, let me know -- I'll re-post it on github --

Found it -- reloaded the repo -- https://github.com/thecarnie/xencoin-seeder

[crackfoo]

I have the xenseed running on seed.hasher.ca now....

You still running this?

Since the main seed node is down (domain gone), if a couple stable ones existed, they can be added to the source. I don't have that source repo anymore -- if you still have a copy, let me know -- I'll re-post it on github --

Found it -- reloaded the repo -- https://github.com/thecarnie/xencoin-seeder

no I'm not running that anymore. I dumped everything too...

[thecarnie]

no I'm not running that anymore. I dumped everything too...

Gotchya.  I did find my original copy of it and re-upped the repo --

I haven't committed the final changes just yet for the client - but so far, I have a working xencoind built (mingw64 on win7x86) from the latest litecoin code (with xnc's changes) running and it's downloading the blockchain.  I have a couple more tests - then I can commit the last couple changes, along with the updated checkpoints from triptech and there it will be.

There's no 'seed nodes' available and I don't want to hard-code the two IPs we have at this time. 

The github repo is not updated with the latest changes just yet.  But it will be shortly.  Once I get a QT build completed.  I haven't tested things on my Debian box yet for the linux side...

There's a couple edits still to go on the makefiles and some better documentation - and it'll be up for grabs.  There's no changes in the code that I know of other than it will follow litecoin's path regarding version 2 blocks.  When I make the final commits the BIP16 and BIP30 will be hard-coded as well since XNC came out after those were implemented in litecoin's code.

[thecarnie]

My repo is updated.  The code has been brought up to Litecoin base 8.7.2, with XNC's merge changes.  I'm halfway through a blockchain download - I do not recommend this client be used on ANY live wallets or production systems, but I could use a couple testers to check things out.  Makefiles for *nix and OS-X may not be up to date.  Most compile instructions found here ( https://bitcointalk.org/index.php?topic=149479.0 ) will work.  I'll be updating the documentation and build instructions for *nix and Windows the moment I have completed more testing and see things to be stable.  I don't have much for mining hardware to test with at the moment.  This means that once I get a QT client successfully built, I'll need someone to mine a few blocks my way so I can test wallet activity.  

These updates bring several major upgrades that XNC was missing.  The protocol is updated to 70002, and block version 2 is also supported.  CoinControl as implemented in Litecoin is in this build (although I haven't tested anything with it yet).

I have been able to compile under MinGW-64/Win7 for the daemon - still getting my QT libraries together properly for a QT build.  Since my old wallet files no longer exist (after the last episode here), I was not able to test wallet import.  I CANNOT STRESS ENOUGH NOT TO USE THIS WITH A PRODUCTION WALLET, but if anyone is willing to work through some builds and some testing, that would help big time.

The issue tracker is live on the Github Repo.  The current code-state is only missing the checkpoints from triptech, because I have to finish downloading the blockchain to get the TX of his last checkpoint.  Another potential issue is there are blocks in this chain that are timestamped before other blocks, but included after them.  We will have to find some checkpoint blocks that don't violate this rule as they are creating an error by the client updates - although still accepted because a couple BIPs are not 'forced' in the XNC code.

[crackfoo]

I'll give the SRC a pull tonight and give it a go. I still have not bed able to sync anything even with the nodes mentioned recently.

[thecarnie]

I'll give the SRC a pull tonight and give it a go. I still have not bed able to sync anything even with the nodes mentioned recently.

I'm up to 540k blocks downloaded since last night when I built my daemon.  I am trying to get the whole blockchain down because I need the TX number from the last checkpoint triptech listed in his patch - that goes on the checkpoints.cpp file in the source and then I can re-build and re-download the checkpointed chain to make sure there are no issues.  IF it downloads ok, then I'll turn the two BIPS on that are currently not 'forced' -- and then another download.

I also haven't added a new seednode in the code yet since there's no domain name to point to an IP yet.  I'll try to get something going on that soon.  I added in the 46.32.253.168 as an addnode in the xencoin.conf file and so far I'm abou 550k blocks down.  Once I get the client completely updated, and can download the whole blockchain without problems, I'll make up a bootstrap.dat file that can be seeded somewhere (that's another of the updates that come with this takeover) --

[thecarnie]

Had to restart the client at 539k - max orphan issue (10,000+) I think it was - the client stopped accepting blocks.  Restart and it's up to 580k.

I propose new diff algo in the future to prevent pool attacks that create tons of orphans.  Fast block times like this create problems in the end when mining on a weak network.

[triptech]

Had to restart the client at 539k - max orphan issue (10,000+) I think it was - the client stopped accepting blocks.  Restart and it's up to 580k.

I propose new diff algo in the future to prevent pool attacks that create tons of orphans.  Fast block times like this create problems in the end when mining on a weak network.

I agree with this and all your other points 'carnie. The 46 node is my own box. Here to stay, I also have others available for permo use approx 4 + 1 capable of 8-12 VPS boxes depending on ram requirements. I have a test on 86.163.167.12:4334 that synced first time around with the 46 node. I'll get another running with your build tomorrow and see what occurs if thats OK? Anything I Can do to help let me know. BTW message on github noted

[thecarnie]

I agree with this and all your other points 'carnie. The 46 node is my own box. Here to stay, I also have others available for permo use approx 4 + 1 capable of 8-12 VPS boxes depending on ram requirements. I have a test on 86.163.167.12:4334 that synced first time around with the 46 node. I'll get another running with your build tomorrow and see what occurs if thats OK? Anything I Can do to help let me know. BTW message on github noted

Sounds like a plan.  Double check the repo -- I will be committing the checkpoint update tonight to the source - I'm about 60k blocks from needing the TX number I need for that file.  So far, other than the shitton of orphans that are in the chain, the client seems to be able do download.  I used your 46 node to seed my client via config file and it took off like a shot.  IRC seeding has been removed from this client as well.  If we get a good seedbox or two up, we should be set.  I also recommend changing the default ports soon before we 'officially' package up binaries for the client.  For some reason when looking in my xenseeder logs and even in the client logs, I see TONS of litecoin clients (by port) coming in and out of my connections -- maybe we can tone that down a little by moving ports.  Not sure yet.

If you're interested, I'm most likely going to register a domain name - if you have a little room anywhere, and I can point a subdomain over to you for a xenseed node to run -- that will help a lot.  We can lock in the address in the client and it will have a seed-node to start with.  As we can add a couple more, we'll code them into the client as well.  I'm about a month out from spinning up another server for my hosting company (16 cores/10tb/64gb ram) and I'll be putting a VM or two on there to keep coin things going for everyone. 

I had some financial setbacks over the last couple months and they albeit stopped me from getting a different coin off the ground -- so for what it's worth - after we get everything stable again, I accept donations

[triptech]

I agree with this and all your other points 'carnie. The 46 node is my own box. Here to stay, I also have others available for permo use approx 4 + 1 capable of 8-12 VPS boxes depending on ram requirements. I have a test on 86.163.167.12:4334 that synced first time around with the 46 node. I'll get another running with your build tomorrow and see what occurs if thats OK? Anything I Can do to help let me know. BTW message on github noted

Sounds like a plan.  Double check the repo -- I will be committing the checkpoint update tonight to the source - I'm about 60k blocks from needing the TX number I need for that file.  So far, other than the shitton of orphans that are in the chain, the client seems to be able do download.  I used your 46 node to seed my client via config file and it took off like a shot.  IRC seeding has been removed from this client as well.  If we get a good seedbox or two up, we should be set.  I also recommend changing the default ports soon before we 'officially' package up binaries for the client.  For some reason when looking in my xenseeder logs and even in the client logs, I see TONS of litecoin clients (by port) coming in and out of my connections -- maybe we can tone that down a little by moving ports.  Not sure yet.

If you're interested, I'm most likely going to register a domain name - if you have a little room anywhere, and I can point a subdomain over to you for a xenseed node to run -- that will help a lot.  We can lock in the address in the client and it will have a seed-node to start with.  As we can add a couple more, we'll code them into the client as well.  I'm about a month out from spinning up another server for my hosting company (16 cores/10tb/64gb ram) and I'll be putting a VM or two on there to keep coin things going for everyone. 

I had some financial setbacks over the last couple months and they albeit stopped me from getting a different coin off the ground -- so for what it's worth - after we get everything stable again, I accept donations

I found a worldcoin client totally fucked my chain at one point -  hte block explorer picked up an extra 40k blocks and it all went a bit wrong - so +1 on the port idea. Also just about to PM you a report. its a large html file but worth checking.

drop me a PM tomorrow around 11am GMT if possible, I'll also going to PM you a report on something I Found. Not sure if its a concern or just usual behavior.

*NOTE* - Anyone having trouble connecting on the 46. node please PM me your IP address and outgoing port. My security system is a touch sensitive!

[thecarnie]

I'm GMT -0600 (CST/DST) - Central USA out here -- but I should be up around that time   Worst case, I'll send you my email address(es) via PM so we can communicate that way as well -- I'm about 775k blocks currently -- so getting there -- I'm interested to see how the client handles the 'endgame' to getting the blockchain downloaded.

What has REALLY screwed this chain up is that when the client was originally written, the magic-bytes that were used are used on a couple other coins - and that is the REAL problem we're having.  Blocks destined for other clients are bombarding ours (and vice-versa) because the chains all share common data.  I'm trying to work out a way to fix that but haven't come up with anything just yet that doesn't involve some sort of hard-fork (which I'm trying to avoid at all costs currently).

Definitely interested in anything you have -- and I'll send an address through shortly --

[thecarnie]

*NOTE* - Anyone having trouble connecting on the 46. node please PM me your IP address and outgoing port. My security system is a touch sensitive!

FWIW - this is one of the reasons I'll spin up a VM - something tiny with plenty of bandwidth to run a couple seeders on.  They way you don't have to back off your security any for nodes to connect.  With the seeder, they'll see it first looking for peerinfo, then only contact your client as needed for blocks and mining (at least, that's how it's supposed to work for new clients)

[crackfoo]

seems I've got up to block:

$ xencoind getmininginfo
{
    "blocks" : 72291,
    "currentblocksize" : 0,
    "currentblocktx" : 0,
    "difficulty" : 0.01529915,
    "errors" : "",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "networkhashps" : 5353102,
    "pooledtx" : 0,
    "testnet" : false
}



but I do see lots of these now:

received block 6ee160855c7135686c23
ProcessBlock: ORPHAN BLOCK, prev=9a148a0769ff65b2330c
received block 26142e91edcc3036522d
ProcessBlock: ORPHAN BLOCK, prev=8dbf5e041ca70c05590a
received block 626cd0f950d9b165c928
disconnecting node [2001:19f0:300:1458:225:90ff:fe89:51aa]:8771
Disconnected [2001:19f0:300:1458:225:90ff:fe89:51aa]:8771 for misbehavior (score=100)
ERROR: ProcessBlock() : block with timestamp before last checkpoint

and:

ERROR: FetchInputs() : 6085481119 mempool Tx prev not found 1be39b21dc
stored orphan tx 6085481119 (mapsz 10)


Stop and start didn't make a difference and this is my current peer list:

$ xencoind getpeerinfo
[
    {
        "addr" : "66.175.220.212:9333",
        "services" : "00000001",
        "lastsend" : 1405913690,
        "lastrecv" : 1405913694,
        "conntime" : 1405913591,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "5.129.241.223:9333",
        "services" : "00000001",
        "lastsend" : 1405913675,
        "lastrecv" : 1405913690,
        "conntime" : 1405913595,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "82.80.166.219:9333",
        "services" : "00000001",
        "lastsend" : 1405913685,
        "lastrecv" : 1405913668,
        "conntime" : 1405913601,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "116.87.210.132:9333",
        "services" : "00000001",
        "lastsend" : 1405913695,
        "lastrecv" : 1405913692,
        "conntime" : 1405913602,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "178.128.73.18:9333",
        "services" : "00000001",
        "lastsend" : 1405913686,
        "lastrecv" : 1405913694,
        "conntime" : 1405913640,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607958,
        "banscore" : 0
    }
]

[thecarnie]

seems I've got up to block:

$ xencoind getmininginfo
{
    "blocks" : 72291,
    "currentblocksize" : 0,
    "currentblocktx" : 0,
    "difficulty" : 0.01529915,
    "errors" : "",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "networkhashps" : 5353102,
    "pooledtx" : 0,
    "testnet" : false
}



but I do see lots of these now:

received block 6ee160855c7135686c23
ProcessBlock: ORPHAN BLOCK, prev=9a148a0769ff65b2330c
received block 26142e91edcc3036522d
ProcessBlock: ORPHAN BLOCK, prev=8dbf5e041ca70c05590a
received block 626cd0f950d9b165c928
disconnecting node [2001:19f0:300:1458:225:90ff:fe89:51aa]:8771
Disconnected [2001:19f0:300:1458:225:90ff:fe89:51aa]:8771 for misbehavior (score=100)
ERROR: ProcessBlock() : block with timestamp before last checkpoint

and:

ERROR: FetchInputs() : 6085481119 mempool Tx prev not found 1be39b21dc
stored orphan tx 6085481119 (mapsz 10)


Stop and start didn't make a difference and this is my current peer list:

$ xencoind getpeerinfo
[
    {
        "addr" : "66.175.220.212:9333",
        "services" : "00000001",
        "lastsend" : 1405913690,
        "lastrecv" : 1405913694,
        "conntime" : 1405913591,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "5.129.241.223:9333",
        "services" : "00000001",
        "lastsend" : 1405913675,
        "lastrecv" : 1405913690,
        "conntime" : 1405913595,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "82.80.166.219:9333",
        "services" : "00000001",
        "lastsend" : 1405913685,
        "lastrecv" : 1405913668,
        "conntime" : 1405913601,
        "version" : 60001,
        "subver" : "/Satoshi:0.6.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "116.87.210.132:9333",
        "services" : "00000001",
        "lastsend" : 1405913695,
        "lastrecv" : 1405913692,
        "conntime" : 1405913602,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607957,
        "banscore" : 0
    },
    {
        "addr" : "178.128.73.18:9333",
        "services" : "00000001",
        "lastsend" : 1405913686,
        "lastrecv" : 1405913694,
        "conntime" : 1405913640,
        "version" : 70002,
        "subver" : "/Satoshi:0.8.5.1/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 607958,
        "banscore" : 0
    }
]

All those 9333's are Litecoin clients (almost guaranteed) -- for some reason, you're getting a high amount of litecoin noise like I am.  My seeder is seeing them as well.  I've made it up to 835270 since last night.  I had to restart once because somewhere it mapped over 10,000 orphans and something died in the client.  When I restarted it, it picked up where it left off.  I only have one addnode in my configuration - triptech's IP.  If you're getting a ton of noise, try deleting the peers.dat file between your next restart, and kick all nodes out of your config other than triptech's.  So far, I've just about managed to DL the whole chain.  Once I get it down, I'm gonna do a bootstrap.dat file so it can be downloaded and imported.  

IF you're working with my repo, part of the sync issue will come from no public seed nodes available yet - until I get a couple seed nodes online, it will have to have addnodes in the config file.  The repo still has the xencoin.com domain in it (and I doubt there was ever a seeder on it) --

Here's the last few lines from my debug.log:

Code:

2014-07-21 04:34:41 received block 7ffedca3e131264a6e513ff22a10621313cd25c1569407c3933ae22747267beb
2014-07-21 04:34:41 ProcessBlock: ORPHAN BLOCK, prev=aab493757dae39314ce62e02f2409816083534fca1946c8b4ce72aa8e1771e3d
2014-07-21 04:34:42 received block 2b04bd35862a3d318f49f3060a806f902490f6912395528a90cfa2c9cdb1082a
2014-07-21 04:34:42 SetBestChain: new best=2b04bd35862a3d318f49f3060a806f902490f6912395528a90cfa2c9cdb1082a  height=839632  log2_work=48.723599  tx=963432  date=2014-07-07 16:47:35 progress=0.224398
2014-07-21 04:34:42 ProcessBlock: ACCEPTED
2014-07-21 04:34:42 received block 6d546ac6cc1b19dc0166bbe7fdd61d95580813960bbad507a00fa0c7feb25c29
2014-07-21 04:34:42 ProcessBlock: ORPHAN BLOCK, prev=7ffedca3e131264a6e513ff22a10621313cd25c1569407c3933ae22747267beb
2014-07-21 04:34:42 received block 32729f9bd347a1bcb4f5f97718745a33cd8bd0e0e1c5080f4697840d5c247ae4
2014-07-21 04:34:42 SetBestChain: new best=32729f9bd347a1bcb4f5f97718745a33cd8bd0e0e1c5080f4697840d5c247ae4  height=839633  log2_work=48.723599  tx=963433  date=2014-07-07 16:47:46 progress=0.224398
2014-07-21 04:34:42 ProcessBlock: ACCEPTED
2014-07-21 04:34:42 received block 783b7e7570d42115f55b9255a4eee5961bc8862a316e1fd265db5b055450d7ae
2014-07-21 04:34:42 ProcessBlock: ORPHAN BLOCK, prev=6d546ac6cc1b19dc0166bbe7fdd61d95580813960bbad507a00fa0c7feb25c29
2014-07-21 04:34:42 received block 627ee7a7cadc42a3bc3c743580df57046fa78b89965af30d2852dcaf64f83455
2014-07-21 04:34:42 SetBestChain: new best=627ee7a7cadc42a3bc3c743580df57046fa78b89965af30d2852dcaf64f83455  height=839634  log2_work=48.723599  tx=963434  date=2014-07-07 16:48:10 progress=0.224399
2014-07-21 04:34:42 ProcessBlock: ACCEPTED
2014-07-21 04:34:42 received block e82b1a219a08406bc28ec86bab1deb618f7ced8d3cab7554249577762eedaf96
2014-07-21 04:34:42 ProcessBlock: ORPHAN BLOCK, prev=783b7e7570d42115f55b9255a4eee5961bc8862a316e1fd265db5b055450d7ae
2014-07-21 04:34:42 received block 5bed8f26f71bdeb008d31ca8f831d08342ed50daf860a680a75cd9813a4c1686
2014-07-21 04:34:42 SetBestChain: new best=5bed8f26f71bdeb008d31ca8f831d08342ed50daf860a680a75cd9813a4c1686  height=839635  log2_work=48.723599  tx=963435  date=2014-07-07 16:48:21 progress=0.224399
2014-07-21 04:34:42 ProcessBlock: ACCEPTED
2014-07-21 04:34:42 received block c29e7d942f2b1d5e700ae479a67aa1cef2ffde4d0615a0225678c58211948f79
2014-07-21 04:34:42 ProcessBlock: ORPHAN BLOCK, prev=e82b1a219a08406bc28ec86bab1deb618f7ced8d3cab7554249577762eedaf96
2014-07-21 04:34:43 received block 94feab15ca68a118ac17ae124a6f5ec23e35639f7c304a95c943a1285b2ffa95
2014-07-21 04:34:43 SetBestChain: new best=94feab15ca68a118ac17ae124a6f5ec23e35639f7c304a95c943a1285b2ffa95  height=839636  log2_work=48.723599  tx=963436  date=2014-07-07 16:48:40 progress=0.224399
2014-07-21 04:34:43 ProcessBlock: ACCEPTED
2014-07-21 04:34:43 received block 79778ac5b0f1b39016fcfa5ef8cbee0f3f3257611474528b8f759c3b5df0f15c
2014-07-21 04:34:43 ProcessBlock: ORPHAN BLOCK, prev=c29e7d942f2b1d5e700ae479a67aa1cef2ffde4d0615a0225678c58211948f79
2014-07-21 04:34:43 received block 54e4a760d42f4ff7dc77e11310276aedcb7a848c19874887d9a71bc27e866bfd

The moment I get the whole chain down, I'm updating the checkpoints in the source and re-building my client to see if it does better pulling down the blockchain.

[thecarnie]

ERROR: FetchInputs() : 6085481119 mempool Tx prev not found 1be39b21dc
stored orphan tx 6085481119 (mapsz 10)

When my client died earlier, my mapsz number was 10001 and throwing a rejection on the block from the orphans.  It happened in the 540k range --

Hopefully, the checkpoints will help -

[thecarnie]

Xencoin Community Fork - Repo updated - checkpoints added - version data changed - https://github.com/thecarnie/xencoin (TESTING - UNSTABLE)
xencoin-seeder - Repo updated - initial seed changed for now - version data changed - https://github.com/thecarnie/xencoin-seeder

The XNC repo has my temporary xenseed node coded in - it should start downloading a blockchain right away without help from nodes in the xencoin.conf file...  Be sure to remove  them and delete your peers.dat file to test if it is connecting and finding nodes as expected.  Still monitoring for a 10k orphan block exception during re-download.  The chain is probably about 1/2 orphans mixed in from the bad diff algo and multi-pools.  Will know more in the morning --

[crackfoo]

Xencoin Community Fork - Repo updated - checkpoints added - version data changed - https://github.com/thecarnie/xencoin (TESTING - UNSTABLE)
xencoin-seeder - Repo updated - initial seed changed for now - version data changed - https://github.com/thecarnie/xencoin-seeder

The XNC repo has my temporary xenseed node coded in - it should start downloading a blockchain right away without help from nodes in the xencoin.conf file...  Be sure to remove  them and delete your peers.dat file to test if it is connecting and finding nodes as expected.  Still monitoring for a 10k orphan block exception during re-download.  The chain is probably about 1/2 orphans mixed in from the bad diff algo and multi-pools.  Will know more in the morning --

Building now. I'll add the coin to www.hasher.ca again for people to test with.

[crackfoo]

Xencoin Community Fork - Repo updated - checkpoints added - version data changed - https://github.com/thecarnie/xencoin (TESTING - UNSTABLE)
xencoin-seeder - Repo updated - initial seed changed for now - version data changed - https://github.com/thecarnie/xencoin-seeder

The XNC repo has my temporary xenseed node coded in - it should start downloading a blockchain right away without help from nodes in the xencoin.conf file...  Be sure to remove  them and delete your peers.dat file to test if it is connecting and finding nodes as expected.  Still monitoring for a 10k orphan block exception during re-download.  The chain is probably about 1/2 orphans mixed in from the bad diff algo and multi-pools.  Will know more in the morning --

Building now. I'll add the coin to www.hasher.ca again for people to test with.

Finished, deleted blk* peers database etc... however, not connecting up:

2014-07-21 12:32:39 send version message: version 70002, blocks=0, us=192.99.35.133:1542, them=98.93.92.131:4334, peer=98.93.92.131:4334
2014-07-21 12:32:39 socket recv error 104
2014-07-21 12:32:39 disconnecting node 98.93.92.131:4334
2014-07-21 12:32:42 trying connection 98.93.92.131:4334 lastseen=73.3hrs
2014-07-21 12:32:42 connected 98.93.92.131:4334
2014-07-21 12:32:42 send version message: version 70002, blocks=0, us=192.99.35.133:1542, them=98.93.92.131:4334, peer=98.93.92.131:4334
2014-07-21 12:32:42 socket closed
2014-07-21 12:32:42 disconnecting node 98.93.92.131:4334
2014-07-21 12:32:44 trying connection 98.93.92.131:4334 lastseen=73.3hrs


$ xencoind getinfo
{
    "version" : 80703,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "connections" : 0,
    "proxy" : "",
    "difficulty" : 0.00024414,
    "testnet" : false,
    "keypoololdest" : 1405451347,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

[thecarnie]

Xencoin Community Fork - Repo updated - checkpoints added - version data changed - https://github.com/thecarnie/xencoin (TESTING - UNSTABLE)
xencoin-seeder - Repo updated - initial seed changed for now - version data changed - https://github.com/thecarnie/xencoin-seeder

The XNC repo has my temporary xenseed node coded in - it should start downloading a blockchain right away without help from nodes in the xencoin.conf file...  Be sure to remove  them and delete your peers.dat file to test if it is connecting and finding nodes as expected.  Still monitoring for a 10k orphan block exception during re-download.  The chain is probably about 1/2 orphans mixed in from the bad diff algo and multi-pools.  Will know more in the morning --

Building now. I'll add the coin to www.hasher.ca again for people to test with.

Finished, deleted blk* peers database etc... however, not connecting up:

2014-07-21 12:32:39 send version message: version 70002, blocks=0, us=192.99.35.133:1542, them=98.93.92.131:4334, peer=98.93.92.131:4334
2014-07-21 12:32:39 socket recv error 104
2014-07-21 12:32:39 disconnecting node 98.93.92.131:4334
2014-07-21 12:32:42 trying connection 98.93.92.131:4334 lastseen=73.3hrs
2014-07-21 12:32:42 connected 98.93.92.131:4334
2014-07-21 12:32:42 send version message: version 70002, blocks=0, us=192.99.35.133:1542, them=98.93.92.131:4334, peer=98.93.92.131:4334
2014-07-21 12:32:42 socket closed
2014-07-21 12:32:42 disconnecting node 98.93.92.131:4334
2014-07-21 12:32:44 trying connection 98.93.92.131:4334 lastseen=73.3hrs


$ xencoind getinfo
{
    "version" : 80703,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "connections" : 0,
    "proxy" : "",
    "difficulty" : 0.00024414,
    "testnet" : false,
    "keypoololdest" : 1405451347,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

THANKS!  That test alone shows several changes have worked.  That IP you're seeing is my DDNS to my node working via the xenseed daemon running on my DL140 over here.  Basically, the source last night has xenseed updated to host our own primary seeder, and I DDNSed my dev servers for now to keep the seeder going because I don't have any linux VMs facing the public at the moment.

The multiple connects to that IP basically show that I'm not down re-downloading the blockchain yet, so I'm not sharing blocks it seems.

I'm currently at about 675k since restarting last night.  The checkpoints seem to have resolved the orphan mapping exhaustion issue I had yesterday, so progress.  You might just shut the daemon down for a little bit on that one -- I'll ping a message up when I have the whole chain down and we can re-test to see if you start syncing up -

Thanks again man!