Yes, the connection errors are piling up as the client is running. A connection refusal/timeout every 5–7 seconds.
It’s been several months since I’ve minted. My nu.conf is configured with:
addnode=198.52.160.71
addnode=198.52.217.4
addnode=198.52.199.75
addnode=198.52.199.46
addnode=162.242.208.43
addnode=192.237.200.146
addnode=119.9.75.189
addnode=119.9.12.63
Connection errors I find are usually fairly normal. You’ll have a big list of IP’s in the peer database and not all of them will always be available. Are you noticing that you get fewer connections with 2.1 than you do with 2.0.3 (let’s say over the course of like 30 minutes)?
@CoinGame Looking back through debug.log, it’s hard to determine previous node availability because I don’t see the timestamps that I’m presently getting. I haven’t been able to mint since early September 2015 and was never able to get 2.0.3 to synch.
I can report one impressive improvement of 2.1.0 compared to 2.0.3 - the memory consumption has, like announced, gone down - to roughly one third.
While nud 2.0.3 occupied above 700 MB, the nud 2.1.0 requires approximately 240 MB:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25309 pi 20 0 441m 237m 9052 S 100.7 24.4 633:25.37 nudUpdate:
Memory usage went up:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25309 pi 20 0 1043m 822m 0 S 178.2 84.5 3841:09 nudnud 2.1.0 is still converting the blockchain files:
tail -n 2 .nu/debug.log
2016-01-13 21:12:07 SetBestChain: new best=01a56356c21d1fb9bf604353ea2fd8c011ebc1f917a0a062b6be2c3a46bd229d height=472951 log2_trust=39.336951 moneysupply(S)=1007201549.1383 moneysupply(B)=4590212.0851 tx=962748 date=2015-08-07 13:34:45 progress=0.003326
2016-01-13 21:12:07 ProcessBlock: ACCEPTEDUpdate2
I needed to restart nud, because the RaPi2 started swapping. Now the memory consumption is low again:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28317 pi 20 0 508m 294m 7556 S 127.3 30.2 66:10.98 nudCan confirm the reduced memory requirements on Linux, but on m y PC it is about 1Gb for Nu 2.03 and around 650Mb for Nu 2.1.
Something else which doesn’t appear to be right is the synchronization. Nu2.1 is 2-3 times slower than 2.03. Earlier I noticed that syncing Nu 2.1 is very slow, but this emphasizes it further.
nud got stuck at block 690,960:
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" : 690960,
"moneysupply" : 833757804.61170006,
"timeoffset" : -4,
"connections" : 8,
"proxy" : "",
"ip" : "redacted",
"difficulty" : 0.000211,
"testnet" : false,
"keypoololdest" : 1452165519,
"keypoolsize" : 101,
"paytxfee" : 1.0,
"errors" : ""
}
tail -n 20 ~/.nu/debug.log
2016-01-15 08:26:00 accepted liquidity info from BEU9G1YCwCtaVa3mMPvX4NcqKngbA2jJ7C
2016-01-15 08:26:00 accepted liquidity info from B8DZADD7UrMkzEmTWyvn2cEoxcnog1D8MK
2016-01-15 08:26:00 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:00 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:01 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:01 received block d072c16c6205814dc239211af9352395236bbadf09862e36e981181e5cdac3c4
2016-01-15 08:26:01 ERROR: CheckProofOfStake() : INFO: check kernel failed on coinstake 55ce9710986bbe72ee4062454be5d7f6cd75fa5e5560f6b1d43fe0213655a1c1, hashProof=0000000000000000000000000000000000000000000000000000000000000000
2016-01-15 08:26:01 WARNING: ProcessBlock(): check proof-of-stake failed for block d072c16c6205814dc239211af9352395236bbadf09862e36e981181e5cdac3c4
2016-01-15 08:26:01 Flushed 9055 addresses to peers.dat 184ms
2016-01-15 08:26:08 ThreadRPCServer method=getinfo
2016-01-15 08:26:08 Misbehaving: 192.230.167.139:7890 (6 -> 7)
2016-01-15 08:26:09 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:09 accepted liquidity info from BEU9G1YCwCtaVa3mMPvX4NcqKngbA2jJ7C
2016-01-15 08:26:09 accepted liquidity info from B8DZADD7UrMkzEmTWyvn2cEoxcnog1D8MK
2016-01-15 08:26:09 accepted liquidity info from BEbkDnBh71ZaXHXkr63HXP4bMda9m9BN7B
2016-01-15 08:26:09 accepted liquidity info from BEbkDnBh71ZaXHXkr63HXP4bMda9m9BN7B
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3I decided to restart nud.
Is that new - “nu-shutoff” after issuing “nud stop”? Haven’t recognized that before. Anyway: nice!
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28317 pi 20 0 829m 652m 6880 R 100.0 67.0 1898:23 nu-shutoffAfter restarting nud, nud stopped. The debug.log shows:
tail -n 20 ~/.nu/debug.log
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
2016-01-15 08:42:01 ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
2016-01-15 08:42:01 ERROR: VerifyDB() : *** block.ReadFromDisk failed at 690915, hash=21c3ce1f5d0cb4828dce3753b2ce8fa5dfb1646a90c608582cb7310e1cd742b6
2016-01-15 08:42:01 : Corrupted block database detected.
Do you want to rebuild the block database now?
2016-01-15 08:42:01 Shutdown : In progress...
2016-01-15 08:42:01 Flush(false)
2016-01-15 08:42:01 DBFlush(false) ended 1ms
2016-01-15 08:42:01 StopNode()
2016-01-15 08:42:01 Flushed 0 addresses to peers.dat 11ms
2016-01-15 08:42:01 Committing 135 changed transactions to coin database...
2016-01-15 08:42:01 Flush(true)
2016-01-15 08:42:01 DBFlush(true) ended 0ms
2016-01-15 08:42:01 Shutdown : doneLooks like converting from BerkeleyDB to LevelDB can’t be done (due to SD card issues?) and I need to sync from scratch, right?
Are there already bootstrap files available for LevelDB?
Update:
syncing from scratch failed at block 8,776 from debug.log:
2016-01-15 10:27:41 WARNING: ProcessBlock(): check proof-of-stake failed for block 40b8290a5d783d1fcae0089e10c34378d87f35ab4604a758ef0ef1cf76b89d6c
And there’s a lot messages about misbehaving nodes in debug.log - whatever that means.
Another finding: it’s impressive how responsive nud is; right after starting it, issuing commands like nud getinfo is possible and lead to output.
I’ve started with syncing the blockchain from scratch once more.
Update2:
Syncing blockchain from scratch got stuck again at block 8,776.
I added
addnode=104.156.247.229
addnode=104.238.165.61
addnode=104.239.228.107
addnode=192.237.200.146
addnode=212.129.19.120
addnode=128.199.96.127
addnode=188.226.223.94(from Super nodes - for nu.conf ) to nu.conf, restarted nud and downloading the blockchain could be continued.
Update3:
nud on my RaPi2 (1 GB RAM) is syncing the blockchain awfully slow (only 46,198 blocks so far with 8 connections in the last 8 hours), but the memory comsumption is (in difference to the database conversion I tried before) constantly on very low level (approx. 125 MB!):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29590 pi 20 0 332m 121m 8684 S 2.3 12.5 270:40.64 nudI’m seeing the same on my 1Gb and 2Gb Linux Debian VPS’s syncing very slow no matter what, but low memory usage of Nud, although 125Mb is a record. I haven’t seen it under 350Mb, 400-450Mb on average, peaks to 600Mb Haven’t encountered being stuck though yet, running for 3 days on a row now. RaPi Nud apparently behaves differently for some reason.
Berkeley DB is used for the conversion but it’s also still used for the wallet. So it’s still required.
Sorry I haven’t posted an update here. Just got back from traveling and may have bricked my laptop trying to move everything over to a bigger hard drive. Fun times! Hopefully will get back into the grind by tomorrow
I did some tests on the initial download. It’s expected to be slower on 2.1 because everything is not kept in memory anymore so the blocks need to be loaded from disk on demand. So I/O speed is an important factor here. But even with optimal I/O and network conditions it’s still 2 times slower. We will try to improve that, but it may be better to start with a bootstrap file.
Does this mean downloading the blockchain from a trusted source instead of on the network initially?
Exactly that!
The blocks still need to be verified by the wallet application, but not downloaded from other Nu network peers.
Weak subjectivity at its finest. We can compile the source code and download directly from peers, but it takes a lot of time and effort. Or we can download from trusted Nu sources both the client and the blockchain. Shouldn’t we offer this bootstrap service? In some ways it’s also like a check pointing process.
They are not the same. Modified source code will compile and run. Modified blockchain will cause a re-download from scratch as I understand, as long as the network you see is good.
So you don’t need to trust the source of bootstrap file if you have trusted peers.
true, so the burden of trust is even less for the boot strap than for the client software. All the more reason why we should offer a direct download, or something.
right. for those paranoids an official sha256 can be provided
Would be good, a full blockchain download took me almost 48h with V2.1.x. Maybe we can setup a torrent as the traffic to host these files might be high and expensive. We could even use something like Joystream later (when out of alpha), to pay users for seeding the files.
+1
Until we have bootstrap files:
would you consider uploading the bare blockchain files somewhere?
Compressing might save some space.
And of course the Nu wallet needs to be exited - but why do I tell you that? 
It would help big time being able to run nud 2.1.0 on my RaPi2, because of the low RAM requirements.
Downloading it on my RaPi2 will take some more days:
Sun Jan 17 17:59:29 UTC 2016
nud getinfo | grep blocks
"blocks" : 205501,
Mon Jan 18 10:24:05 UTC 2016
nud getinfo | grep blocks
"blocks" : 264482,60,000 blocks in 16 hours or roughly 90,000 per day if the download speed stays the same.
Will send you a PM
Haven’t tried yet, just have it running for 5 consecutive days. When no issues, I might give it a go over the weekend now I’ve just managed to copy the files to another instance of Nu without downloading them from scratch.