[00:02:45] but regarding line 802 in my gist, i still can't figure out why the number will go up and down echo Consensus Parameter Change Proposed: $(nav_cli 0 listconsultations | jq ".[].version" | grep 13 | wc -l) does the version of a consultation change at any point [00:03:16] nope [00:03:31] so strange [00:03:44] is there something wrong with taht line of code? [00:05:03] ill commit a patch [00:05:05] maybe is that [00:05:11] okay [00:05:26] done [00:06:30] can't see it yet [00:06:47] pushd [00:06:50] building [00:07:54] what do you think about the script? what do you think is missing etc. [00:09:08] i can take it [00:09:16] 😭 [00:10:57] unless i miss something id say its quite complete, it covers consultations, consultation answers, range consultations, consensus consultations and abstentions which are the new features [00:11:08] only light wallet voting is missing, but there's no rpc command for that [00:11:53] right, i haven't defined the consensus changes for things like NAVNS [00:12:42] cool cool, giving it a go once it finishes building [00:12:56] did you find anything about the verifychain fail? [00:13:02] not yet [00:13:20] im running it now with only 2 nodes so its easier to compare data if something fails [00:14:21] cool, i noticed that when there are few nodes, they don't stake as often in the beginning. i take that it's because all coins are immature cuz they're used to create consultations/proposals? [00:14:36] might be [00:35:10] im also realising now that the report is not progressing [00:35:20] https://cdn.discordapp.com/attachments/416000318149754881/657002994843254796/unknown.png [00:35:22] the report? [00:35:32] but if i check the logs, they are both in block 480 [00:35:49] yeah i've tweaked the numbers on my script now so hopefully it'll run [00:36:11] oh wait one of the nodes is not [00:36:11] but the nodes don't seem to be able to sync [00:36:15] i was looking the wrong debug [00:40:24] the nodes forked and the script did not detect it [00:40:38] hmm [00:40:57] how? the check state hash should report it [00:41:00] hmmmmm [00:41:10] 2019-12-18 22:57:04 ERROR: IsValidConsultationAnswer: Duplicated answers are forbidden. 2019-12-18 22:57:04 Misbehaving: 127.0.0.1:10001 (0 -> 10) 2019-12-18 22:57:04 InvalidChainFound: invalid block=ecfdee9422b710025f940d2748a3974fa6098836a8732a79dd00e26535d12aa6 height=339 log2_work=28.136018 date=2019-12-18 22:56:32 2019-12-18 22:57:04 InvalidChainFound: current [00:41:11] best=7c6fbade484181b4273d2dcb0f73c9dd4e47e442031edae4a370eb072f4d51a8 height=338 log2_work=28.13088 date=2019-12-18 22:56:16 2019-12-18 22:57:04 ERROR: ConnectTip(): ConnectBlock ecfdee9422b710025f940d2748a3974fa6098836a8732a79dd00e26535d12aa6 failed: 2019-12-18 22:57:04 InvalidChainFound: invalid block=ecfdee9422b710025f940d2748a3974fa6098836a8732a79dd00e26535d12aa6 height=339 log2_work=28.136018 date=2019-12-18 22:56:32 2019-12-18 [00:41:11] 22:57:04 InvalidChainFound: current best=7c6fbade484181b4273d2dcb0f73c9dd4e47e442031edae4a370eb072f4d51a8 height=338 log2_work=28.13088 date=2019-12-18 22:56:16 [00:46:02] my script failed right in the beginning [00:47:56] what did it say? [00:48:21] echo Consensus Parameter Change Proposed: $(nav_cli 0 listconsultations | jq ".[].version" | grep 13 | wc -l) [00:48:35] I wrote listproposals output to ./devnet./listproposals.out in /tmp/tmp.hyCApvJ2if /tmp/tmp.REoBsxRnUY /tmp/tmp.wsJ24rTned /tmp/tmp.5fn6SNKMjC [00:49:02] failed comparing listproposals ? [00:49:09] or hashes? [00:49:28] failed comparing statehash [00:49:34] running again [00:49:41] what do the logs say? [00:49:49] do they show ERROR: IsValidConsultationAnswer: Duplicated answers are forbidden. [00:49:50] ? [00:50:46] checkingt [00:51:40] yes, there is that error [00:52:02] it might be because of how i wrote the script [00:52:18] once a consultation is created, the script will try to randomly add answers to it [00:52:35] and for consensus parameters, the random answers are limited within the range i set [00:52:42] which can have duplicates fairly easily [00:52:45] i think its a bug [00:53:03] and consultation answers are not removed when a block is disconnected if the answers were created together with the consultation [00:53:25] i see [00:53:36] well, i'd be thrilled if the script is actually finding bugs [00:53:51] im sure it does [00:53:54] 😉 [00:53:57] 🙂 [00:57:59] okay the script is failing again [01:28:10] script still failing, but i've updated the script so it should run more smoothly now [01:28:30] and correctly tracking consensus parameter changes [01:32:26] and all stress node debug logs will be stored to the folder /tmp/stresser_faillogs$RANDOM so it's easier to compre [01:49:44] i had to restart my gitan build for 4.7.2 sorry [01:49:49] so im still waiting on hash confirmation [01:49:56] did yours match alex's @salmonskinroll [01:49:56] ? [01:50:09] umm... how do i check his? [01:50:44] alex's hashes are posted in the master.SHA256SUM.asc file on his build server [01:50:45] https://build.nav.community/binaries/master/ [01:50:58] okay, let me have a look [01:54:43] yeah mine matched with his. @prole [01:54:47] great [01:55:21] ill start to put together the website update, social posts and all that and as soon as my gitian finishes and i also confirm i can press publish [01:55:34] sounds good. [01:56:04] we might have found a bug with the DAO branch. i wonder if it's worth waiting for him to confirm that that bug would not affect current master [01:56:35] mostly likely not related since it's a consultation related bug [01:56:36] okay, ill get the posts lined up anyway [01:56:41] sounds good [02:46:34] PR is up for review on navcoin.org https://github.com/navcoin/navcoin-org/pull/260 [03:12:58] approved. while you're at it, can you take a look at https://github.com/navcoin/navcoin-org/pull/256 [03:14:12] @aguycalled my script is failing at verifychain phase now when i run with 1 node. this never happened before the new commit today. [04:35:14] my gitian hashes match [04:35:14] https://builds.navcore.org/4.7.2/ [05:50:13] so everything is ready to get pushed out once alex gives the go ahead. im going to step away from the computer for the rest of the evening so ill check on the chat later and then push the release tomorrow morning if we're going ahead [07:02:57] script updated. fixing counting block cycle correctly if consensus parameter changed and some performance tweaking. [08:51:09] yes you can go ahead wth the release [08:51:27] what i found is exclusive to the dao_extension branch [08:59:26] Okay great [09:00:00] I've attached the binaries to the github release. I'll do the website merge and social publishing tomorrow morning [09:00:15] And exchange notification and the rest [09:00:18] 😎 [19:15:13] im be trying to add checks to monitor if the consensus changes are reflected on aactual proposals and consultations [20:27:20] i think thats better checked on the python functional tests so this does not get overcomplicated [20:27:38] what do you think? [20:45:09] Yeah. Either way it's probably best to at least have it on python functional tests. [22:21:50] im thinking two good additions to the script would be [22:21:57] random node restarts [22:22:11] and random disconnections and reconnections between nodes [22:22:25] hmm, okay [22:22:32] maybe not easy to implement [22:22:40] for restarts do you mean a clean resync [22:22:44] or just a restart [22:22:53] navcoin-cli stop and then start again [22:23:00] or kill the process and then start again [22:23:06] okie dokie. or we can have both [22:23:06] both alternatives [22:23:13] clean and dirty restarts [22:23:16] starting up new nodes, killing current ones etc [22:23:42] sounds good. i'll work on it [22:24:00] ive patched navcoind and been testing the script for a while [22:24:09] havent seen the issue yet but will keep it running a bit more [22:24:17] one problem with random disconnecting and reconnecting is that it might cause network split [22:24:23] did you use the latset script? [22:24:56] when was it updated? [22:24:57] 15h ago? [22:25:12] yupi [22:25:19] then yes [22:25:22] cool [22:26:05] for disconnecting and reconnecting, what do you want exactly? [22:26:39] just randomly drop them? does the node that drops a connection still need to be connected to the network somehow? [22:26:44] or completely off the grid [22:27:07] my thoughts are about isolating a stresser node, so it is left staking alone and then needs to readjust the chain [22:27:43] a node, or a portion of the network [22:28:07] leaving the stressers alone, what about the rest of hte network, are they staking? [22:28:50] yes, but i think itd be important to have at least 1 stresser in the isolated side so there are still new things coming together with new blocks [22:28:58] does that make sense? [22:29:31] i think so, so basically you want a network split and both/all sides are stressing their networks, and the combine them to see what's up [22:29:51] yes, i think that's a extreme real life situation [22:30:07] i think that should be doable with all the functions i have already set up [22:30:16] creating networks will be easy [22:30:24] coo cool [22:30:25] 👌