' 5: from ./bin/gbuild:307:in `each' 4: from ./bin/gbuild:309:in `block in

' 3: from ./bin/gbuild:309:in `each' 2: from ./bin/gbuild:314:in `block (2 levels) in

' 1: from ./bin/gbuild:164:in `build_one_configuration' ./bin/gbuild:21:in `system!': failed to run [13:30:46] on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) [13:32:24] i checked the build log and my gitian build process timed out trying to retrieve Fetching xtrans-1.3.4.tar.bz2 from http://xorg.freedesktop.org/releases/individual/lib/ and Fetching xtrans-1.3.4.tar.bz2 from https://build.nav.community/depends-sources [13:34:01] Are you running that on OSX? [13:34:14] If you are, you will have to use gitian from @prole's fork [13:34:24] It has patches to work on OSX [13:34:53] Hmmm, that sounds like a networking issue [13:35:05] So might not be gitian itself. [13:35:20] Can you try downloading the dependencies manually if they work? [13:35:26] @mc290 [13:35:53] i'm running on ubuntu [13:38:23] I see, so it's not an issue with gitian then [13:38:36] Can you try manually downloading the files that timeout? [13:38:56] i can wget the first from the first source [13:39:16] Hmmm [13:39:29] Connection Refused from https://build.nav.community/depends-sources [13:39:39] The second URL is a fallback [13:39:43] So it should not matter [13:39:50] It tries that URL if the first one fails [13:43:40] hmm actually my gitian build failed yesterday trying to get a different dependency zeromq [13:44:15] timed out as well [13:45:45] i'll try the docker build again. see if it times out in the same place. if it does, maybe Alex can unblock me from https://build.nav.community/depends-sources [13:51:05] oh my bad [13:51:38] i need to set up again that been moving vps and the build.* server is off [13:52:19] that would be helpful but i'm not sure why i'm not connecting to the primary sources [13:53:29] the urls might be outdated? [13:54:43] well you guys are building fine so I suppose you are retrieving the depends from the same urls [13:56:04] maybe it's just a network issue on my side [13:56:23] too much netflix [14:30:31] My build used the original source [14:30:36] So they should be up [14:30:47] Maybe network issue like you said [14:37:21] I think gitian will cache the source files once it's downloaded them [14:37:52] So on next run it should proceed without having to re-download the sources already fetch from last build [14:38:01] I guess just try again @mc290 [15:48:49] ive added xtrans to the depends-sources [15:49:23] let me know if any other package is needed [15:49:38] @mc290 [16:04:19] # ls /var/www/html/depends-sources/ 807d6fd1be5d2224872e381870c0a75387fe05e6.tar.gz dbus-1.8.6.tar.gz libdmg-hfsplus-v0.1.tar.gz qtbase-opensource-src-5.9.8.tar.xz xcb-proto-1.10.tar.bz2 biplist-1.0.3.tar.gz expat-2.2.6.tar.bz2 libxcb-1.10.tar.bz2 qttools-opensource-src-5.9.8.tar.xz xextproto-7.3.0.tar.bz2 boost_1_64_0.tar.bz2 [16:04:20] fontconfig-2.12.1.tar.bz2 miniupnpc-2.0.20180203.tar.gz qttranslations-opensource-src-5.9.8.tar.xz xproto-7.0.26.tar.bz2 cdrkit-1.1.11.tar.bz2 freetype-2.7.1.tar.bz2 openssl-1.0.1k.tar.gz release-2.1.8-stable.tar.gz xtrans-1.3.4.tar.bz2 clang-llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz libX11-1.6.2.tar.bz2 protobuf-2.6.1.tar.bz2 [16:04:20] unbound-1.9.0.tar.gz zeromq-4.3.1.tar.gz curl-7.64.1.tar.xz libXau-1.0.8.tar.bz2 qrencode-3.4.4.tar.bz2 v1.1.2.tar.gz zlib-1.2.11.tar.gz db-4.8.30.NC.tar.gz libXext-1.3.2.tar.bz2 qtbase-opensource-src-5.7.1.tar.gz [17:02:46] @aguycalled [17:03:05] I did a full sync on the master branch + the fix for glibc compat [17:03:10] And I ran into an issue [17:03:13] 2019-06-26 09:20:34 ERROR: IsValidPaymentRequest: Invalid requested amount for payment request 1511446b6441a1686d67b3cf59c87f104b63c118c75b8c0c33d753f562a2b679 (2505000010000 vs 0 available) [17:03:34] But I was able to fix it by invalidateblock 1511446b6441a1686d67b3cf59c87f104b63c118c75b8c0c33d753f562a2b679 then reconsiderblock 1511446b6441a1686d67b3cf59c87f104b63c118c75b8c0c33d753f562a2b679 [17:03:44] Not sure if this is related to cfund [17:03:48] Have any thoughts? [17:03:55] Therre were no other errors in logs [17:03:56] Just that [17:03:58] looks like a cfund db bug but that should be solved [17:04:11] It's not the same as the old bugs [17:04:28] As this one I was able to recover by simple reconsiderblock that errored hash [17:04:49] IIRC the old bug would need to back track several blocks to recover [17:05:47] What does the (2505000010000 vs 0 available) mean? [17:06:03] 1st is the amount requested second the amount available in the proposal [17:06:12] Ahh, I see [17:06:22] BTW, my node did not fork when it happened [17:06:27] It just would not accept new blocks [17:07:02] do you think you would be able to reproduce it [17:07:13] I honesly don't know [17:07:23] Nothing happened to the node [17:07:31] It was still up and runniing [17:07:53] Only thing that happened was a network loss (Then network came back a few minutes later) [17:08:04] Maybe a corrupted UDP packet? [17:08:18] I can't think of anything else, as the node did not crash either [17:09:16] CAmount CFund::CProposal::GetAvailable(CCoinsViewCache& coins, bool fIncludeRequests) const { AssertLockHeld(cs_main); CAmount initial = nAmount; CPaymentRequestMap mapPaymentRequests; LogPrintf("[CFUND] >> Checking available balance for proposal %s\n", ToString(coins, chainActive.Tip()->GetBlockTime())); if(coins.GetAllPaymentRequests(mapPaymentRequests)) { for (CPaymentRequestMap::iterator [17:09:16] it_ = mapPaymentRequests.begin(); it_ != mapPaymentRequests.end(); it_++) { CFund::CPaymentRequest prequest; if (!coins.GetPaymentRequest(it_->first, prequest)) continue; if (prequest.proposalhash != hash) continue; if (!coins.HaveCoins(prequest.hash)) { CBlockIndex* pindex; if(prequest.txblockhash == uint256() || [17:09:17] !mapBlockIndex.count(prequest.txblockhash)) continue; pindex = mapBlockIndex[prequest.txblockhash]; if(!chainActive.Contains(pindex)) continue; } if((fIncludeRequests && prequest.fState != REJECTED && prequest.fState != EXPIRED) || (!fIncludeRequests && prequest.fState == ACCEPTED)) { LogPrintf("[CFUND] >> Substracting %d [17:09:17] from payment request %s\n", prequest.ToString()); initial -= prequest.nAmount; } } } return initial; } [17:09:29] could you add this extra logging and try to resync again to see if it happens? [17:09:32] and lets see what the log say [17:09:50] Ok, will do. [17:09:54] Whcih file does that go in? [17:10:04] NVM, found it [17:10:12] So, another full sync right? [17:11:42] yep [18:13:28] Will post back when done [18:22:51] @aguycalled [18:22:55] In other news [18:23:06] I think I've got the path stuff almost [18:23:11] that's great [18:23:22] I was having a bit of trouble creating the root key [18:23:30] Might have the PR ready soon [18:23:52] I'm basically copying the logic from the bip44 implementation in JS [18:24:43] let me know when its ready and ill have a look [18:24:57] That Ian Coleman made [18:25:03] Ack [18:25:16] The library will have support for text paths [18:25:25] So we just for the path as a full string [18:25:35] Then get the keys from the function [18:25:52] Takes a seed/entropy as input + the path [18:26:09] Then spits out a key pair [18:26:32] Based my logic from here: https://iancoleman.io/bip39/ [18:28:20] so new wallets use the new path while older wallets will still work, right [18:29:50] Yes [18:29:51] That is the plan [18:30:09] I'm adding a path prefix value to the wallet.dat [18:30:26] And if it does not exist wallet uses the old logic to get keys [18:30:57] And will add a new flag via cli or conf for the path when importing a new mnemonic [18:37:58] I'm sure I will need feedback on the security aspect, i feel like keeping the keys in memory is dangerous. But I can't figure out if the current implementation has the same problem [18:38:32] But then again, is someone has access to your system memory, the could just as easy take the base seed/entropy [18:38:35] @aguycalled [18:39:08] The keys will be in memory if you unlock the wallet or are in the middle of signing a tx right? [18:39:41] if the wallet is encrypted, and the wallet is unlocked [18:39:48] the wallet password is kept in memory [18:40:07] Ok, and the key is in memory while signing a tx. [18:40:19] Or singing a message etc. [18:40:25] yes [18:40:29] /** * secure_allocator is defined in allocators.h * CPrivKey is a serialized private key, with all parameters included (279 bytes) */ typedef std::vector > CPrivKey; [18:40:46] this is cleared from memory when destroyed iirc [18:41:04] // // Allocator that locks its contents from being paged // out of memory and clears its contents before deletion. // template struct secure_allocator : public std::allocator { ... [18:41:42] but the wallet password is always in memory, specially when staking [18:42:39] Ok [18:47:39] So as long as the keys are cleared after use, it should be fine? [19:03:22] i'll have a look at the code when its ready to know better what the changes are [22:52:59] im currently testing https://github.com/navcoin/navcoin-core/pull/549 [22:53:14] what is next after this? do we need more fixes for the invalid block described above? [23:27:36] stil llooking at it [23:27:43] did u see it again @mxaddict ? [23:34:04] i can try to reindex 549 and see if i encounter any stuck block [23:36:45] 549 is only related to an issue reported by marcus, where the gui would not launch in unix [23:36:51] the invalid block is different