17:02:49 Meeting in a bit less than 1 hour 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1311 18:00:38 hey 18:02:34 Hmm ... people busy Christmas shopping maybe :) 18:02:50 *waves* 18:02:51 sorry 18:03:15 Alright, what are the reports about last week? 18:03:37 while updating https://github.com/monero-project/monero-gui/pull/4437 I also fixed some issues I didn't notice before 18:03:44 began to look back into the problem with setting restore height on wallet creation with the GUI 18:03:45 also wrote a CCS proposal, but haven't made a merge request yet. Maybe someone wants to have a look first and give feedback https://repo.getmonero.org/SNeedlewoods/ccs-proposals/-/blob/SNeedlewoods-03_part-time_dev_work-Q1-26/SNeedlewoods-03_part-time_dev_work-Q1-26 18:04:42 Do you have something reviewable already for the Wallet API and the use of that in the CLI wallet? 18:06:04 Will have a look at your CCS proposal 18:06:05 Not sure I understand, but this is "reviewable" I guess https://github.com/monero-project/monero/pull/10233 18:06:56 I mean you don't plan to immediately change it again significantly, what could make an on-going review invalid so to say 18:08:24 Solved some lingering issues with the daemon/wallet2 noticed during stressnet (sporadic repeated double spend errors in the wallet, some connection drop issues), investigated/identified a cause of what looked like a regression in sync perf (depends builds are slow, GUIX builds fast), implemented jeffro's review comments on multithreaded verify. Continuing this week with tx relay v 2, getting all outstanding PR's shaped up, and may dig into a segfault reported by ofrn 18:08:27 the only thing I'm planning to fix is "outgoing pending txs not showing up in `show_transfers`", else it should be pretty much done 18:08:53 I assume some things will change because of review though 18:09:22 "tx relay v2" is a pretty big change, right? 18:09:57 Or maybe I confuse it with something else 18:10:42 it is, it's mostly implemented by 0xfffc already, but I have some changes in mind pointed out in review that I want to implement 18:11:22 and plan to work with 0xff on that 18:11:38 the current PR for reference: https://github.com/seraphis-migration/monero/pull/184 18:11:51 That could be quite a big step forward 18:12:06 Especially in times of many transactions 18:12:46 yep, we also apparently have some relay issues in the daemon, so I want to see this in the daemon first and then tackle the relay issues 18:12:57 Howdy sorry I'm late 18:13:12 Not sure what you mean with "relay issues" 18:13:24 https://github.com/seraphis-migration/monero/issues/163 18:13:54 Ah, ok. Might be present for quite a while already, but only surfacing now 18:14:04 seems to be the case 18:16:27 SNeedlewoods: you don't have to lower your paid hours for those reasons. you can include the time you expect to spend working in your proposal fine, no one should have an issue with that 18:16:50 jeffro256: What kept you busy during last week? 18:18:16 Working on tx knowledge proofs integration (decode, spend, reserve, etc) 18:19:09 Anything that is significantly more complex now among those because of Carrot? 18:19:11 Hoping to get that done this week 18:20:24 Uh not significantly in term of concepts, but now there's a bit more business logic because of different transactions types, and the difference b/t internal and external enotes. It's also probably going to require some RPC changes to the daemon 18:21:26 Ok, if that's the worst that happens, quite alright :) 18:22:16 Alright, anything to discuss beyond reports today? 18:23:17 stressnet didnt die with sustained 20+mb blocks 18:23:23 thanks for your feedback, but I don't think I would feel well asking for more, I would like to give more than I take if possible 18:23:53 Main issue is probably that when templates are >2800txs, xmrig has problems connecting, and mining a block with it will crash the node 18:24:02 your call! 18:24:21 My old desktop server sounding like a jet engine tho 18:24:31 Lol 18:24:44 Mining large blocks were often reorged by empty blocks, so thats potentially an issue - that people can produce artificially small blocks to win the block race 18:24:56 Finally working like it should have all the time already 18:25:40 laptop fans been spinning non-stop for days 18:26:13 Is mining large blocks indeed somehow significantly slower? Where does that slowing happen, is that known? 18:26:31 Cpu usage spikes hard when getting alt chains 18:26:39 very rough idea that probably has problems: maybe difficulty should also factor in n txs 18:27:02 Probably can improve that logic to now download alt blocks unless the alt chain is longer than yours.. currently it seems to always download them (and probabky re-verifying the txs in them) 18:27:17 to not* download 18:28:00 Essentially, your node gets hammered with alt blocks (which could be bullshit attempts at selfish mining) even if your chain is longer 18:28:46 But those alt blocks need to be correct regarding RandomX? 18:28:51 alt block handling does need a pass 18:29:18 Another entry on a long list of such things maybe ... 18:29:19 yea, theyre valid blocks, just not an equal or longer chain 18:30:26 That severly limits the potential to use them as some sort of DoS attack I guess, as long as our code does not handle them with good performance 18:31:05 Yeah, not fcmp problem, but ive seen my nodes becomes slightly unresponsive when adding alt blocks that have no chance of overtaking. And if my chain is longer, then my chain should be pushed to the peer. Currently (master) it works fine because the small blocks are sent to them fast enough to force them to reorg, but on stressnet the peer keep mining blocks on their shorter chain before syncing the blocks from the longer chain 18:31:22 Reorg doesnt happen until theyve actually synced the final block that surpasses their chain height 18:31:40 So you can essentially game this by setting your download speed to something low, so you dont receive blocks fast 18:33:07 anyway, not an fcmp issue. Just a big block issue 18:33:57 Aka "the bug" ... as it was brutally simplified in some Reddit discussions ... 18:34:32 Correct the "bug", and no more block size limit needed, presto :) 18:35:01 Well, not everybody can be a dev and know how awfully interconnected things can be 18:36:25 Alright, looks like we may be through with immediately important things for now. Thanks everybody for attending, read you again next week! 18:38:20 thanks, see ya 18:39:35 I H8 the txpool 18:40:38 So many issues stemmed from the pool 🥲 18:42:40 it's significantly improving with the latest ya?? seems like just the not relayed issue is the last remaining main thing 18:43:07 and I guess that segfault but I don't think that's a txpool issue 18:44:41 I "think" this might be related to v2 18:45:02 are you running v2? 18:45:19 I dropped v2 commits recently, so not anymore 18:46:04 you were running v2 when you encountered this too? https://github.com/seraphis-migration/monero/issues/163 18:46:14 looks like v2 might be relaying txs 1 at a time 18:47:21 Honestly not sure. I think no 18:47:34 With v2 i was seeing 1000-15000 not relayed 18:47:49 Honestly not sure. I think not 18:49:30 the current v2 PR has an issue where it silently stops relaying >100 txs 18:49:52 which is one of the things I was going to work on 18:50:47 so ya, we'll see where we're at post-tx relay v2 once ready, and with some other changes to re-relaying for I made strictly for stressnet rolled back 18:51:06 Sounds good 18:58:10 also, eventually we probably want to get rid of the auto-ban change on stressnet.. we really should solve all the issues causing unexpected /extraneous bans and nodes should be able to stay connected during stressnet 18:58:24 sorry the auto unban* 18:58:29 after 2 mins 19:10:26 <0​xfffc:monero.social> Let me know if there any help I can do