16:59:56 Meeting in 1 hour 18:00:20 Meeting time. Hello! https://github.com/monero-project/meta/issues/1449 18:00:35 hello 18:00:40 Hello 18:02:10 Hey 18:02:12 waves 18:02:23 Me: worked on review comments, submitted a few PRs, updating AUR packages for Cuprate, doing some HW wallet testing for SNeedlewoods, attempted to replace GNU Readline with linenoise in epee 18:02:35 Alright, what is there to report about the 2 last weeks? 18:03:09 Last week's meeting fell victim to a Matrix server which was down ... 18:03:12 received lots of reviews for #9464, #10232, #10233 and #10819 and working through those 18:03:45 Yeah, you were committing almost daily 18:04:21 sorry for the annoyance 18:04:58 @dangerousfreedom:matrix.org left a detailed report in this room earlier today. It seems he has reached quite some milestone, with a first working version of his MoneroInflation update for FCMP++. See e.g. here: https://github.com/monero-project/meta/issues/1449 18:05:14 Oh, no, wrong of course. This: https://github.com/DangerousFreedom1984/monero_inflation_checker 18:05:53 I worked mostly on Serai this past week, no significant update on my end re: FCMP++. Checking back up on things today 18:06:41 He also made a post on Reddit about it: https://old.reddit.com/r/Monero/comments/1w3hcos/monero_inflation_checker_fcmp/ 18:07:19 is the Python port of monero-oxide AI? 18:08:11 I've been busy replacing Guix with Stagex, and glibc with musl+mimalloc for release builds. Benchmarks so far show greatly reduced memory usage for beta-stressnet sync and better performance on checkpointed syncs. https://github.com/monero-project/monero/pull/10223 18:08:18 I don't read everything carefully, but I think he said something about no large-scale vibe coding. Not sure which parts he meant. 18:08:29 Talking about monero oxide, it's it OK to start making a new wallet using that, instead of wallet2? 18:09:17 I'm finding large scale AI comments, so that's why I was asking. I have been (manually) been making a Go port of quite the same + other non-port from-scratch implementations which is why I was curious 18:09:17 @ravfx:xmr.mx: I think you'd want to be using monero-wallet-util instead, but a few projects are seemingly adopting it already 18:09:35 https://github.com/monero-oxide/monero-wallet-util 18:09:36 @ravfx:xmr.mx: it has been audited 18:09:58 He might see your question here, DataHoarder ... 18:09:59 oh cool, thanks for all answers 18:10:24 Jumping ship, eh? :) 18:10:45 I'd use monero oxide over wallet2 if I was presented with the choice today fwiw 18:11:18 I made my own tooling to avoid wallet2 >.< 18:11:20 gonna be quite a few things to need to work through though that wallet2 handles out of the box 18:12:03 yeah, monero-oxide is not the same level of wallet lib as wallet2 18:12:16 like wallet state management, reorg handling, storing the wallet files encrypted, and a whole lot more 18:12:38 Sounds like some chances to shoot into your feet ... 18:12:47 yeah, it's utilities/scanners that can be used to make a wallet2 equivalent or better 18:14:20 monero-oxide: monero blockchain impl 18:14:20 monero-wallet: wallet core implemented with the above 18:14:20 monero-wallet-utils: even more wallet tools 18:14:20 there's still a lot of gap to fill between those and wallet2[... more lines follow, see https://mrelay.p2pool.observer/e/lqCblKYLQzZCaXVO ] 18:14:24 Might be quite some way until things settle on a new wallet file format that is portable between apps, based on monero-oxide 18:14:59 you can import the wallet2 cpp files etc into monero-oxide et al or just transfer the relevant key material? 18:15:10 Or maybe that won't happen again, and it's restoring with seed if you change apps 18:15:14 @rbrunner7: Or a new one could be standardized, maybe using an actual KDF 18:16:16 @jbabb:cypherstack.com: and to be clear: I mean, with a custom reader. I have code for this .keys->monero-wallet somewhere, let me find it... 18:18:08 I also have a subject that I want to bring up: I wonder how to bring my Polyseed PR over the finishing line and make it merge-ready. This here of course: https://github.com/monero-project/monero/pull/10765 18:18:39 A lot of people have reviewed and contributed, but now it's question how to walk the last few meters, so to say 18:19:13 Maybe selsta and/or @tobtoht:monero.social can have a look about the state and give some advice? 18:19:52 @jpk68:matrix.org: You talked about going through some points that an AI based review has found and submit what passes a first smell test? Is that still in the works? 18:20:24 And I just saw today that I have to rebase 18:21:14 @rbrunner7: Apologies, I will get around to that soon. Though I don't think it's found anything too noteworthy that hasn't been surfaced already. 18:21:38 Wanted to do a final review, but was too busy with my PRs. I can try to prioritize it this week 18:21:40 Ah, and I guess I wait for tevador's Polyseed licensing getting merged so that I can update the Polyseed submodule 18:21:55 My apologies for being late to the meeting - @tobtoht:monero.social: are we dropping guix for stagex ? I installed guix on a purism box man, so much pain lol 18:21:57 *Polyseed re-licensing 18:22:19 @vtnerd: That is the plan. No more pain. 18:22:59 Ok, I guess I'm keeping this crazy box for stagex builds then, it's been interesting learning guix as an os 18:22:59 for wallet2 .keys files -> monero-oxide-land: https://github.com/ManyMath/monero-rust/blob/staging/rust/monero-rust/src/wallet_keys_file.rs 18:24:05 Alright, seems I will have some work still to do for that PR 18:25:08 So, anything left to discuss today? 18:25:16 I have a sort of open-ended question regarding some work I had planned to do, if that's fine 18:25:32 Shoot, we have still time to fill the hour :) 18:25:47 In my most recent CCS, I proposed working on integrating the Tor Control protocol into monerod, which would allow for automatic management and monitoring of Tor connectivity. Unlike I2P SAM, Tor Control isn't a replacement for SOCKS, and instead works alongside it. 18:25:47 However, I have recently become unconvinced that this integration is worthwhile, for a few main reasons: 18:25:47 1. The protocol is being phased out in favour of a new JSON-based standard, which comes with Arti (a newer Tor implementation in Rust). Tor Control is only supported in the 'legacy' C implementation of Tor, which will also be deprecated in a few years.[... more lines follow, see https://mrelay.p2pool.observer/e/g5rFlKYLaUYtWEp3 ] 18:26:59 Open to feedback on this; there may be something else that is in greater need of more people working on it :) 18:27:59 Would that also need a bunch of new monerod interactive console commands and startup parameters? We have quite a number of those already ... 18:28:36 Not sure about console commands, but it would probably need one or two more startup flags, yes 18:28:59 @jpk68:matrix.org: I didn't see a great need to add Tor Control. 18:29:14 jpk, do you have a link to the new spec? I see the old at https://spec.torproject.org/control-spec/index.html , might be helpful for context? makes sense to move to arti to this rustacean but I know TC vs the new spec 18:30:20 @jbabb:cypherstack.com: https://people.torproject.org/~nickm/volatile/rpc-reference.html 18:30:23 s/vs/whereas I'm new to 18:30:56 I think it could be somewhat useful, though it's worth noting that Arti is still considered somewhat 'unstable' for the time being 18:31:14 Not sure if people think this is something worth having in the core codebase; would be good to hear opinions :) 18:31:28 But on the other hand we would get more code, new dependencies, some more config 18:31:58 I don't think any dependencies would be required; I would just write it in C++ with existing machinery 18:32:04 Why would a Monero user want to control Tor circuits through monerod? 18:32:35 personally I like monerod and potentially more tools being more aware of if it has a real/alive tor connection 18:32:46 @rucknium: It can create ephemeral hidden services, rather than having the user manually set them up. 18:32:57 More knobs to twist so YouTubers have more things to fill their videos? :P 18:33:52 jpk, you'd know better: what's the state of a killswitch if a tor conn drops etc? have you looked into that? 18:34:31 @jpk68:matrix.org: I guess that's a little more convenience. 18:34:42 @jbabb:cypherstack.com: What do you mean? You can't run the daemon purely through Tor, at least not while syncing the chain 18:35:11 So, unlike something similar to Mullvad's kill switch, you'd just not be able to send transactions/some peer data anymore 18:36:06 like if you are trying to broadcast a tx over tor, is there awareness of the state of the tor connection? so if it goes down it doesn't transmit? I haven't looked into this area in years and forget 18:36:59 anyways, my main point is just that that's an important function to work towards or maintain 18:37:07 I think most of that is opaque when using a regular Tor SOCKS proxy, and the Tor daemon itself will take care of that 18:37:13 @jbabb:cypherstack.com: Yes, that would be nice, if possible 18:39:30 Maybe you could put up a GitHub issue to hopefully get some feedback from people not attending right now 18:39:41 In addition to the discussion here 18:40:05 Tor socks generally does the "right thing" iirc, as in it generates a new circuit for each socks connection 18:40:56 The tor browser doesn't use the control connection afaik, so it's designed with that use case in mind 18:41:22 Regarding other things worthwhile to work on, I think we will have plenty of those in connection with FCMP++ and Carrot hardfork, but it may still take a while until it becomes clear what it really is 18:42:11 Yes, if anyone has odds and ends they think I'd be qualified to work on, or PRs that need reviews, just throw them at me ;) 18:43:26 Alright. That flag is planted :) I think we can close the meeting proper here. Thanks everybody for attending. Read you again next week - if the Matrix server allows it lol 18:44:12 thanks everyone 18:44:14 @rbrunner7: funnily restarted the bridge about 35s before the meeting for some updates :) 18:45:06 Oh. I use to take the meeting content from IRC to format it into the meeting log. 18:45:54 But have to say, the bridge works quite well now, with plenty of little details that "just work right". Solid. 19:53:22 :) yeah all messages are there. Just need to get edits "right enough" 20:12:21 @jbabb:cypherstack.com: txproxy? Txs dont broadcast 20:12:54 They stay in the nodes txpool until tor/i2pis restored