[00:01:11] ready @salmonskinroll [00:01:26] Wow. Building. [00:01:58] sorry push failed [00:02:00] now [00:05:35] ok [00:22:28] i think i've now went through and fixed all your reported issues [00:22:33] let me know if i've missed anything [00:22:44] or if the reorg issue is still there for you [00:23:06] did you fix 42? [00:23:25] i didn't notice the conversion but i do now so it's probably okay. but then the problem will be in range consultation "0" will not be voted even if set. [00:23:42] still building now so i can't tell [00:23:45] i'll confirm it [00:24:30] im not able to type 00000 in the max field [00:25:25] yeah i should probably make a seperate issue, but waht i was saying is actually that 0000 should be fine, but if i have a range consultation say 0 to 100, i cannot vote on 0 [00:25:35] it gets converted to 1 automatically [00:25:36] i dont know if its because i fixed it or because my system [00:25:44] only 0 cannot be voted on thought, not the lower limit [00:26:05] sorry i was not clear [00:26:16] they are probably separate issues [00:39:00] @aguycalled reorg issue seems solved 🙂 great job [00:40:43] 👌 [00:45:43] okay, just confirmed 0 cannot be voted on in range consultation [00:45:50] yes im working on that now [00:45:59] will fix it before getting in bed [00:46:22] don't work too hard 😉 [00:52:52] fixed [00:53:04] amazing [00:53:37] i'll go over all the issues again and start doing the network test [00:54:52] https://github.com/navcoin/navcoin-core/issues/619 [00:55:57] looks like @salmonskinroll is done testing the dao. how is your availability looking for testing from your side? @prole @mxaddict [02:06:46] With all the network split, 4.7.1 release and Nio drama behind us i am on track to spend my 2 dedicated NavCoin days this week continuing to try and review and test the DAO. It likely to be my Saturday & Sunday the way my schedule is looking right now. [02:08:14] First step is going to be catching up with where you guys are at and what is already done because i haven't been looking at it much over the last couple of weeks and you've been steaming ahead [02:08:53] you guys sound like you're confident this is at an alpha stage now with most major issues ironed out? [03:01:10] Yeah. I have tested all consensus parameter changes as well as normal answer and range consultations. You can see it in my check list of all the testing I did. I will spend today and tomorrow to go over all the issues to make sure they are all fixed. If they are, I am confident that it's in alpha phase if not beta and I'll have 6 or more nodes running it to simulate real world situation. And if all goes well on that for a [03:01:10] week or two, I will approve the PR @prole [03:02:37] nice [03:04:20] what do you think is the highest priority for me to verify at this point? i was going to probably focus on the consensus parameter change stuff since it has the highest potential impact if something goes wrong. [03:06:05] followed by the regular voting, which could even though they aren't causing concrete actions on chain (like consensus changes, or cfund payments), could cause networks splits like we've seen with the community fund [03:07:42] for me these are the two highest priority areas; 1) extensive and exhaustive test coverage and review of the consensus parameter change capabilities 2) extensive and exhaustive test coverage and review of anything to do with the consultations which could cause network disagreement [03:08:31] followed by more routine coverage of other areas of the consultation process less likely to cause network issues. [03:10:07] i can either work from the top down or the bottom up. I was personally starting at the bottom up with the simple cases first and building ontop of them towards more complex and high risk cases. but im open to suggestions [03:12:22] given our recent network splits the whole DAO is likely considered "high priority" and should not be released until extremely exhaustive test cases are written and testnet has been operating happily for many cycles [04:18:52] consultations and consensus changes are pretty intertwined since a consensus change is a consultation with different end behavior. network splitting is a big problem indeed and should be carefully tested. regarding consensus changes itself, although it is serious but most of the parameters actually do not affect the network that greatly like "minimum % required for a consultation to be accepted". we just need to be careful [04:18:53] with what numbers can be proposed and what effects they will bring like proposing 101% quorum. i have tested it with a variety of conditions and i think the limitations are pretty defined now safe so users cannot propose something that would cause any problems. but this would be the highest risk item i'd say. for consultations, exhaustive test coverage is definitely necessary and I think i have done just that. for the past more than a month i [04:18:53] have spent most of the time on consultations. it'll be nice for another person to do it from a different angle though. networks splitting can be hard to detect with consultations since sometimes the nodes will be on the same network and same blockhash but having different voting counts. this has been fixed but definitely still need keeping an eye on. Another big thing with this is re-orging. Nodes that re-org need to behave correctly say if two [04:18:54] chains having different consensus parameters, once a node re-org to the longest chain, it should have the correct consensus parameter despite what was voted in the wrong chain. i have covered these as well but still i'd say this is a high risk item for sure since having only one chain but different consensus parameters can be really bad. for cfund, it didn't change from what we have now and we even fixed an existing issue. [04:18:54] Overall, for you, i'd say that checking the code logistics might be a good place for you since that's something i don't have much expertise on. besides that, approaching from a different angle would be nice so i think either going bottom up or top down should be fine. [04:25:22] i know it might be hard but i really hope that we can have a release candidate by the end of this year. [04:46:30] noted. when i say "extensive testing" i more mean automated python tests. i know you have been doing an amazing job so far bro, myself and im sure the rest of the community are eternally grateful for your efforts! [04:46:42] ❤ [04:47:55] my plan is basically to write a shit tonne of python tests covering everything i can think of and explore the code as i go [04:48:08] so it will be different from your more user centric testing methods [04:48:29] and i think worthwhile to do both extensively [04:48:36] plus alex's test [04:48:45] plus whatever else we manage to shake out on the test net [04:51:05] yeah definitely, i am thinking about writing some python tests as well. one thing though, we noticed that some behavior only shows up and staking mode and not in block generation mode, that's why aguycalled wrote a test for staking. generally in my experience so far, the code behaves quite well with generated block but not so much in staking mode. so tests in staking mode might be necessary as well [04:51:40] and im very glad that i can help 🙂 [04:52:11] okay nice, good to know [04:52:58] i think its one of those things that we are going to end up with some overlap in what we're all doing, its probably unavoidable, but to be honest its probably the only way to build assurance that we've caught everything [04:53:42] im real anxious about releasing more bespoke code around the consensus mechanism without it being combed over with a microscope by like 10 different people [04:53:58] hopefully i can start to make some pace this weekend! [09:53:43] networks splitting can be hard to detect with consultations since sometimes the nodes will be on the same network and same blockhash but having different voting counts. if this happen in a real world scenario it can cause a network split, so it's definitely something to report if you see it @salmonskinroll [09:57:45] we noticed that some behavior only shows up in staking mode and not in block generation mode, that's why aguycalled wrote a test for staking. this is because of the voter state cache, which allows votes to be broadcast only once. they are only used when staking, because you can not identify who is the miner when a block is generated [15:23:31] syncing from scratch on windows 7 worked without problem. [16:10:02] mmm weird