NuBits 2.1.1 Release

CoinGame 2016-02-27 17:19:01 UTC #1

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.

Fixed issues:

Other issues slotted to be fixed in 2.1.1 (This may increase):

[Slow blockchain download from peers] (https://bitbucket.org/JordanLeePeershares/nubit/issues/227/slow-initial-download-in-21)
Incorrect NuBits balance displayed in QT app
Minting suspended message shows even when NSR wallet is unlocked

I’ve locked the 2.1 release thread and we can continue discussions of issues with it in this thread to focus on the 2.1.1 release.

Nu 2.1.0 has been released [do not upgrade yet, see latest posts]

willy 2016-02-27 23:08:00 UTC #2

I’ve noticed that the block count on my nud 2.1.0 on anton hangs sometimes for a couple of hours.

A restart seems to help. Blocks will be gathered again.

Anton, Berta and the two ALix servers will roll back tonight, as 2.1.0 is unusable for me at the moment.

CoinGame 2016-02-27 23:13:15 UTC #3

Is it connected to any peers during this period?

willy 2016-02-27 23:13:26 UTC #4

CoinGame 2016-02-27 23:14:17 UTC #5

Connected to that many peers and it doesn’t collect any blocks? There must be something in the logs.

willy 2016-02-27 23:18:20 UTC #6

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.

CoinGame 2016-02-28 10:29:43 UTC #7

woodstockmerkle 2016-03-02 01:43:32 UTC #8

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.

willy 2016-03-02 11:38:06 UTC #9

My recent rollback showed the following:

HDD: about 30 hours
SSD: about 15 hours

sportscliche 2016-03-02 16:22:04 UTC #10

Memory usage will increase over time. After running for a little more than a day, 2.1.0 consumes about 1 Gb.

mhps 2016-03-03 00:45:19 UTC #11

starting nud on ram-disk has been tried with good results before.

mhps 2016-03-05 02:48:45 UTC #12

My v2.0.3-beta on RPi has died twice in the last two months with these at the end of debug.log

EXCEPTION: St9bad_alloc
std::bad_alloc
nu in ThreadDumpAddress()

don’t know if the new version also has it.

GLnp 2016-03-08 13:20:34 UTC #13

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:

2016-03-08 13:05:50 ERROR: CheckProofOfStake() : INFO: check kernel failed on coinstake 332a2917dd7eaa9b93d77bd0dc7e3314b5a86e3ccec2abc4eeaec75d360e7ce1, hashProof=90b1486f259aabd2d9122df1aa1b529be0623cbf77a8cb4d2fc1121e05941efa
2016-03-08 13:05:50 WARNING: ProcessBlock(): check proof-of-stake failed for block c34de955a7a4eb646258b23d5db1a75fe8cf4f749bd74836d9e27d4f32e7ad55

Is there a fork or something?

woodstockmerkle 2016-03-08 20:46:53 UTC #14

GLnp-

The chain I am on includes that block as #778761

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?

woodstockmerkle 2016-03-09 05:04:07 UTC #15

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.

woodstockmerkle 2016-03-11 03:17:40 UTC #16

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?

mhps 2016-03-11 05:19:53 UTC #17

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.

sportscliche 2016-03-13 10:06:30 UTC #18

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.

masterOfDisaster 2016-03-13 11:08:32 UTC #19

That’s strange. I have 2.1.0 running on one of ma RaPis

nud getinfo
{
    "version" : "v2.1.0-RC8-dirty-beta",
    "protocolversion" : 2000000,
    "walletversion" : 1,
    "walletunit" : "S",
    "balance" : 0.0,
    "newmint" : 0.0,
    "stake" : 0.0,
    "parked" : 0.0,
    "blocks" : 786133,

and the RAM consumption (39.3% of 1 GB) is quite low:

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
23048 pi        20   0  606m 383m 5916 S  33.3 39.3   2523:06 nud

As you can see from the total CPU time, this nud is running for a while.

Is the difference that I have no NSR?

CoinGame 2016-03-13 11:16:17 UTC #20

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: