Meeting time. Hello! https://github.com/monero-project/meta/issues/1485 hi waves Hi hi Alright, what are your reports from last week? mostly reviews on p2p PRs against the Nvx attack +1 Reviewed tevador's relative lock PR, and incorporated it into the upstream FCMP++ consensus integration PR (about to push those changes, tevador reviewed it) s/Nvx/Nyx I lost overview a bit, do we currently have several different approaches how to combat spy nodes and eclipse attacks, or did we already settle on one? Maybe only differences in small details? I think @0xfffc:monero.social and @ofrnxmr:monero.social have posted a work-in-progress: https://github.com/monero-project/monero/pull/11707 It includes part of my small PR and a lot of their own suggestions Would this go on top of your work then, @rucknium:monero.social , for yet more "effect"? I hope it has more effect. I don't think these specific changes have been tested in monerosim. I think @ofrnxmr:monero.social is very determined to show it to these spies :) AFAICT there are changes that go on top or are independent of Ruckniums changes but the bucketing for example would get rid of the increase of the white peer list Those proposed changes includes my changes to prioritizing white_list instead of gray_list and selecting from the white_list uniformly randomly. It does not include my increase to the white_list size. However, it changes the structure of the white_list so that there is an increase in the total size of it. I don't know exactly how much. Ok, so this will probably develop further for a time. And with everything simulated, as far as possible, I suppose. 256*32 IIRC Howdy yesterday I worked on https://github.com/monero-project/monero/pull/11712 me: working on issues on #10916 related to core_tests, relay, and pruning #10916 being an important PR to get right for the FCMP++ transition +1 +1 Stressnet still running smoothly, right? Nobody is double-spending your precious coins :) @sneedlewoods: correction: that's for the gray bucket, the white one is 256*16 src (https://github.com/0xFFFC0000/monero/blob/59cce9bf868d33d39e15cc62e694f42d59364f4c/src/cryptonote_config.h#L140-L148) @jeffro256:monero.social: this PR is in merge queue https://github.com/monero-project/monero/pull/11655 you might want to review it before it gets merged. @rbrunner7: seems to be, although we haven't kicked stressing back up again Ah yes, that critical time "between the hardforks" Where we once had, to exagerate a bit, quite a shock moment You don't plan a follow-up to that :) @rbrunner7: what was the shock moment? Not sure I remember correctly, maybe a possible chain split was in the air? As worst case outcome Or a standstill of the blockchain? There was a detectable inflation vulnerability in the "between hf" code, and the first followup fix was insufficient. There still is a related consensus splitting vuln during that period that should be fixed by 10916 +1 Its finished > <@rucknium> I think @0xfffc:monero.social and @ofrnxmr:monero.social have posted a work-in-progress: https://github.com/monero-project/monero/pull/11707 Hello I refered to an earlier hardfork where we had some problems with verifying some transactions, if I remember correctly @rucknium: 4096 white and 8192 gray Hi @rbrunner7:monero.social: Last hard fork some txs in the txpool were dropped because their fee wasn't high enough Me: working on random fixes and improvements for the GUI, follow-up linenoise hardening, fixing tests, P2P behaviour patches, looking into design choices for the HTTP server In beta stressnet v2 we had an issue with the modified scaling code strictly for beta stressnet (with the code that shortened the long term window), that caused a net split on the stressnet v2 maybe you're thinking of that @sneedlewoods: Yeah, 256 * 32 for gray, 256 * 16 for white @rucknium: I actually have a TODO item to do a deeper investigation to make sure we avoid this also in the TODO list for launch +1 I think of something that is maybe 2 years back, or even more. But not really important, I clearly see that we are checking everything very carefully now @rucknium: 11707 as posted initially was what was tested on monerosim There have been a handful of fixed from reviews since then +1 Me: lws has been updated to reflect latest fcmp++ code, lwsf will be handled later this week @rbrunner7: the original cause of this PR sounds like what you're referring to: https://github.com/monero-project/monero/pull/7169 there was a reddit post describing the issue that happened back then, I can't find it though Yes, thanks, I think that was it. A tricky case that we only noticed as the hardfork was in full swing already, as far as I remember :) Much fun was had back then, in the good old times Ok, do we have something special to discuss today beyond these reports? I want to mention the discussion about signing commits that we had here or over in -dev yesterday. But yes, wrt the nyx/eclipse/peerlist stuff, 11681/682/683/705/706/707(707 is the full series) are all open. There is 1 ai review that needs to be addresses on 11681, the rest appear to be clean What I took from the discussion that it would be a good idea to encourage people to sign more of their PRs, and more often +1 But that any strict requirement "Only signed PRs" would probably interfere with the flow of PR, and put strain on maintainers it'd be good if maintainers always sign their commits, and ideally also long term contributors +1 +1 if it's a new contributor there is not much point to it because there is no identity to verify in the first place +1 Consider the encouragement done for today :) Anything else? wrt 681, 682, 683, 705, 706, they were all opened alone because they dont interfere with anyone elses work we got added to the anthropic scanner, but so far it's unclear how much compute they allocate to each project +1 Ah, yes, let's see what we will get out of that how do you do that ofrnxmr I think I can close the meeting here. Thanks eveybody for attending, read you again next week! +1 Thank you thanks everyone I removed the "refuse InProofs for transactions the wallet sent" change from the merge queue for now until we decided if this breaking change is acceptable Thanks everyone