Topic: [ANN][XNC] XenCoin | Instant | Stable | Long term Support - New UPDATE!!! - page 7. (Read 75744 times)

Ok great. What block should we actually be on, for the correct chain?

I started up my windows wallet and it sync'd up to 830k+

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!

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" : ""
}

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

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 --

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 -

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
    }
]

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)

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 --

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!

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 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

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'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) --

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.

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://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479 ) 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.

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.

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

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