Meeting time. Hello! https://github.com/monero-project/meta/issues/1481 waves Hello hi Ok, while some other people may still calculate local time in UTC let's start with the reports :) hi some more Wallet API fixes, and tried to look into jpks coin control PR for GUI, but got distracted Yes, some parts from your work "fast-tracked", dutifully coordinated, right? Me: rebasing PRs, working on adding doc comments for the P2P sync protocol, attempting to get SAM reviews, etc. @rbrunner7: yes FCMP++ db tree building PR was merged upstream, looked into logs for tx relay v2 from stressnet and it's looking solid I'd say that's ready to go, separately worked a bit on Serai. This week planning on doing followup on FCMP++ integration PR's, reviewing some outstanding items for Carrot, and updating FCMP++ integration code with the relative lock impl by tevador Yes, forgot about that. That was another task of this week, too :) (adding coin control support to the GUI) As a little chit-chat: I noticed that interestingband aka perfect daemon aka perfect anon made a comeback and hinted at things to come from them. That may get interesting. IMHO a quite capable dev, but often their own worst enemy :) So FCMP++ and Carrot are still progressing without major roadbumps, which is nice. Multisig is not yet ready to test, as far as I know? Not sure, but koe has it on a public branch, in case you were curious Yeah, it depends how easy it would be to get that into a testable state Me: being a dick to new contributors who submit technically correct patches that solve issues that dont exist +1 +1 +1 +1 Lol Like typos. Typos, everywhere, I tell you jeffro and koe are in discussion on next items to get multisig across AFAIK, but I do think it's mostly a matter of resolving some final items in Carrot It's really difficult sometimes to distinguish good faith attempts and pure nonsense oh, im not even referring to that. There was a pr, rebiewed by like 5 ppl, and nobody (including ai) noticed that the issue was solved months ago -She/Wallops- We've recently deployed some new features! This latest batch includes bot mode, a "restrict bots" channel mode, and support for the +channel-context message tag. Find out more at https://libera.chat/news/new-and-upcoming-features-4 Do you have a link? Sounds intriguing I think it would be a bit of a stretch to call this newest PR “bad faith” https://github.com/monero-project/monero/pull/11484 Just someone new who hasn’t spent forever keeping up with stuff here, lol @jpk68: I didnt say that Hi Right, didn’t say you did, I’m just saying in general Should have used single quotes Yes, I was also referring to new devs quite in general Anyway, I am sure we will muddle through without too many bruises all around @ofrnxmr: This is an example on why im hard on the "reviewed/approved by a human" thing Anything noteworthy from you from last week, @vtnerd:monero.social ? Not related to #nwlb. Working on updating my lws patches for fcmp++ right now though Ok, thanks I got a round of pr/fixes for lws which was nice It looks like we are through with the reports. Anything special to discuss today? Just a question abour carrot keted wallets - are we planning to wire them in before the fork, or after? Keyed* You mean the new Carrot key hierarchy? yeah, they arent wired up on stressnet so im basically asking if, at the fork, we will keep using legacy wallets initially? Cuz i assume we want to test them instead of just launching them I think that will be quite some work to integrate those. I think there was talk to indeed introduce that only after the hardfork, but that talk must be months ago already now +1 last we discussed my view was launch with legacy, and release Carrot wallets when it's ready Makes sense. Thanks I don't know if this should be discussed here or wait until the MRL meeting: https://github.com/monero-project/monero/pull/11527 "p2p: increase white_list size and change connection selection algorithm" And is this when I do the "review beg" thing? Wrt nyx, 0xfffc opened a few prs that fix issues found while working on my branch You may get some more eyeballs on this here :) What is "your branch"? And with the latest result showing that /24 deduplication works as-is, i think rushing a fix isnt as prudent as beforr @ofrnxmr: I noticed at least one came up in the LLM review(s) of my PR. It was out of scope of my PR, but good to do. @rbrunner7: My proprietary work :) Half joking. Its the version that rucknium tested against his, and against master https://mrelay.p2pool.observer/m/monero.social/wCHlJJTauSaaghjuRNUsTyol.png (2026-10-28_14-40-08_1793198408403_monero.social_YmycgdTxvbPSWmUVvVSFuyyD_outbound-adversaries-unreachable-10per.png) @rucknium: u talking about my review? Currently the eclipse attack essentially only works as advertised, if the attacker is distributed into 1 ip per /24 subnet Your bot's review and xmrack's bot review. I don't remember now which one, or both, found the problem with not cutting banlist nodes from the initiate p2p.bin file when first loaded so its not as much as an imminent threat as proposed imo. With 10 ips per subnet, the /24 dedup works Frankly, currently I worry more about privacy coins falling left and right after exploits, and then having to rewind the blockchain, or even worse throw in the towel altogether ... @rucknium: That is one of the prs that 0x opened Didnt find it from an externam review Yes. That is what I was referring to. @rucknium: btw link to my review is: https://matrix.to/#/!pxC-ffjul4TyFBniToRC2qswOw4Joszzzwd9YJipuq0/$kz9J3YoPmVRDbNFlpmMauW085FAoI8eHfwDdtna1niM?via=monero.social&via=matrix.org&via=catgirl.cloud https://github.com/monero-project/monero/pull/11651 if u need a re-review (once it's about to get merged) I'll do @thomasbuilds: PR #11651 addresses the bot's #6 issue +1 If things continue like that, we will soon be the last privacy coin without a big crater in it after an exploit +1 +1 https://github.com/monero-project/monero/pull/11652 this is another related issue @rbrunner7: Yes, I am afraid That’s not surprising, though, because we’re the best :D Most of the vulnerable coins had a codebase audit. Some of them had more than one audit. @jpk68: LOL +1 Oh, they found the way here So yes, id like to review beg for 11651 11652 and 11653. All pretty small changes and bug fixes to our p2p code. They go with my kupstreaming my branch" in pieces instead of all at once (and dont conflict with ruckniums work. Much of it doesnt) Ok. Anything else left to discuss in the frame of this meeting? Does not look like it. So thanks everybody for attending, read you again in 1 week! +1 thanks everyone Thank everyone, cya. Happy halloween yeah so worth saying that now xmrack reviews exclude PRs with high findings they are reported privately Yeah i noticed a pr to avoid posting if the findings contain inflation, consensus, or privacy issues Just pre-existing ones, or all of them? @thomasbuilds: and will be made public if no issues, I was told "high" = "critical" I suppose? Oh, one thing i wanted to bring up. Xmrack has a pr to require json enpoints be post, which requires our non-json endpoints (like /get_info) to sent an empty body I personally think i want to nack that, since it breaks like, everythinf, for a read-only endpoint @rbrunner7: well not really tbh, I noticed this because I was looking up the review for my 11655 and couldn't find it and when I was given the justification it was stuff I already raised in PR description in the not covered section