The Nu 2.1 release clearly had a lot of issues for a lot of users. For that reason exposure to the 2.1 release was pulled back and we are working on a 2.1.1 release.
Some of the issues reported on the 2.1 release have been addressed, and we’re working on the other ones. @woodstockmerkle has joined the team on a part time basis to assist in achieving these goals.
debug.log is overwritten as it resynced after restart. My nudroids were showing me that anton’s nud was about 15 hours behind but still running and with a ton of active connections.
There is evidence that new block notifications being received by clients that are downloading are causing the node ban score to be incremented. After enough blocks, the connected node(s) are considered banned. With enough peers, the Nu client will reconnect to the network; however after several cycles of this, a client may become effectively isolated from the network.
If anyone is willing to try a workaround (temporarily for testing!):
In your nu.conf,
add “banscore=20000”
This will have to be reverted at some point as it does slightly increase the risk to the node and the network.
I am curious how long it takes to download the full blockchain as well. Under test conditions, on a SSD, I was able to complete a download in about 13 hours.
There is a second issue I am narrowing in on related to performance for those with spinning disk. Downloads will take much longer – possibly days.
I don’t know if it’s related to v2.1, but my client hangs at block 778760, and it’s 5 hours behind now. Restarting it doesn’t help. There are messages like this one in debug.log:
The coinstake transaction it’s tripping over 332a29 seems to be healthy at first look as well. It references a transaction fc7d3d7 in block 768438 that had just come mature (a 10323 block difference – it would have matured after 10080 minutes). Since we download blocks in swaths of 500, I wonder if something is wrong with how the time-calculation is done – as 500 minutes could make it seem as not being mature.
Before the “ERROR: CheckProofOfStake”, are there any other messages reference to
CheckStakeKernelHash or GetKernelStakeModifier?
I’ve been looking into this, and was able to see the error message on a different block. I haven’t been able to consistently reproduce it. However my download continued, albeit very slowly – 1 block per second or so with heavy CPU usage, and lots of orphan blocks and misbehaving.
As a note, the client tracks whether it is downloading the blockchain en masse. Once the client receives a block that is within 1 day of now(), some of the logic functions differently.
GLnp’s problem was reported when the client was 5 hours behind, so that in between time window could be a factor where these problems are exacerbated.
When downloading, the client is very aggressive about asking all of its peers for its blockchain. As such it is very likely for blocks to be received out-of-order – they are stored as orphans, and have the potential to get linked into the chain as more information comes in. However, I’m wondering if this is causing problems.
So after some further digging, these errors are likely because when a client is downloading from multiple parents, the download may not be contiguous – i.e.: the client may have blocks 1-1000 and 1200-2000.
I think in this specific case the client is trying to validate the equivalent of a block at 1200 but needs data from the missing area, and is therefore failing. This is not the fault of the parent, but of the state of the chain the downloader has; it should not be penalizing the parent (I don’t think it is).
However it’s plausible that it is causing the client to do wasteful computations and bogging down. This may be an area to improve on.
Just curious @GLnp, did this ever resolve for you, or are you in a stuck download state?
If this were the cause of the problem it would have been solved by bitcoin a long time ago, wouldn’t it? downloading blocks from multiple peers is not new.
The memory demands of Nu 2.1 have now exceeded 2 Gb on my Ubuntu box and blockchain synch has been lost. This appears to be a repeat of my experience with 2.0.3; I will no longer be able to support the network.
Just to update everyone: @woodstockmerkle has already submitted some pull requests that do have some improvements. If anyone is running Linux and knows how to compile the client you can try out the changes for yourself by merging in these pull requests.
For me it has significantly improved downloading the blockchain from peers.
My understanding from their discussions regarding memeory is that there are some events that will still cause the memory to rise. We’re in the process of finding out what all of those events are, or implementing a more comprehensive solution to the memory problem. You can see more of that discussion on this issue: