16:53:59 Meeting in a bit more than 1 hour 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1456 18:00:06 Howdy 18:00:12 Hey 18:00:13 Hello 18:00:51 hi 18:00:54 waves 18:01:04 Hi 18:01:33 Summer lull seems to be over, many people here :) 18:01:43 Alright, what are your reports from last week? 18:01:51 rebased, fixed conflicts and updated #9464 (https://github.com/monero-project/monero/pull/9464), #10232 (https://github.com/monero-project/monero/pull/10232), #10233 (https://github.com/monero-project/monero/pull/10233), #10819 (https://github.com/monero-project/monero/pull/10819) with latest round of LLM review comments 18:02:01 Me: Polyseed PR merge ready, or at least almost so 18:02:59 @sneedlewoods_xmr:matrix.org: Those LLM reviews, were they solid? Any comments? 18:03:00 Me: worked on some patches for the core repo and GUI, more AI 'audits' for I2P SAM, reviewed quite a few PRs 18:03:00 Mostly worked on Hackerone reports and tried to make progress on the release. AI makes it so easy to low severity find edge cases that it's kinda becoming unsustainable with our existing bug bounty. 18:04:04 You mean, we may start to classify submissions? 18:04:10 hot-cold PR review and release PR's 18:04:11 To HackerOne 18:04:35 @rbrunner7: Most of the comments I received were valid, some were very helpful 18:04:44 I don't know what the solution is. Maybe increase the minimum amount of severity to be eligible for a bounty. 18:05:06 bumping minimum severity makes sense imo 18:05:08 Yes, that's what I meant with classifying. 18:05:30 me: working on a version compatibility testing framework. It's something that I've been wanting for months now, but I'm getting around to it now. You will able to put in a list of "control commits" and a "target commit". Then the framework will compile all those commits then run a suite of C++/Python functional tests against ( [... too long, see https://mrelay.p2pool.observer/e/047f1KoLTFNwNXp2 ] 18:05:31 Although that may lead to conflicts with submitters ... 18:05:44 First public commit will be in the next couple of days 18:06:45 Sounds interesting, if a bit on the complex side 18:06:53 jeffro256: Is this something we can run on CI our better for specific changes manually? 18:08:31 Maybe interesting for Cuprate as well, at least the general approach? 18:08:34 Yeah I don't see why not. It'll be pretty heavy due to all the compiling involved, but I'm making it configurable, so you can filter out only the needed test suites and needed control commits 18:09:19 What's it written in? 18:09:38 Python/C++/C 18:11:01 Will be interesting to see what you needed C for in there :) 18:11:40 just for FFI basically 18:11:59 With Python? Boost.Python can always work ;) 18:12:37 So this "hold/cold" PR and its review makes steady progress, and we are nearing its merge, right? And then on to a new version of stressnet! 18:13:11 True, but Boost.Python is probably a bit overkill for what I need 18:14:03 Will koe's multisig PR become easily testable only after that merge? 18:14:39 And probably on the new stressnet as well 18:15:28 If koe wants to maintain backwards compatibility for multisig code until the fork, then I imagine that my framework would be very useful 18:15:47 Speaking of multisig, just throwing this out there: I was wondering about the possibility of using monero-oxide's FROSTLASS scheme over FFI. It's already been audited, and provides better security assumptions than the current scheme. 18:15:54 IIUC, it would not require any new dependencies 18:16:25 It would require more work, of course, hence why I'm just surfacing it for no particular reason 18:17:31 That would also start a pretty fundamental discussion whether we want multisig in the core repo at all, or if a separate one is a better place. Not an easy decision at all, if you ask me. 18:18:26 Right, but I meant as more of a drop-in replacement, which happens to use the Rust code, since that's what's being used for FCMP++ anyways 18:18:53 And you could even start to dream about a mid-to-far future where we can leave the C++ code itself behind and do pure Rust, of course with that multisig 18:19:36 Well, something that would make all existing Monero multisig wallets inoperable could not be a "drop-in replacement", seems to me 18:19:53 With "wallets", I mean wallet files 18:21:21 True. This does provide a very good opportunity, IMO, where it could be moved out of 'experimental', due to already having proofs/audits for both the math and implementation code 18:21:51 The fact that multisig in the main codebase is marked as 'experimental' makes for less of a compulsion, if you will, to maintain strict backwards compatibility 18:22:17 Oh, personally I don't think that this "exerimental" disclaimer really hinders actual use ... 18:22:25 Haveno is running fine 18:22:57 Well, it had bumps in the road, but as far as I know more on the protocol side, not with multisig itself 18:23:17 @rbrunner7: That it's 'experimental' is the reason it can't be in the GUI, or suggested to anyone, or be suggested to anyone without lots of disclaimers 18:23:44 FROSTLASS doesn't have the scaling problems, and provides a two-round DKG independent of the number of signers, IIRC 18:24:12 In the meantime you can also claim that if the AIs don't find anything, that is on the reassuring side :) 18:25:01 Reassuring enough to convince people here to remove the 'experimental' label? 18:25:14 No, that's asking too much. 18:25:55 The UX improvements provided by FROST cannot be understated 18:26:55 Don't know. You just have to wait a bit longer in that standalone multisig GUI - how is it called again? - because more rounds take place. UI impact: Almost zero 18:27:19 Something where you have to cut and past your messages manually, even with FROST, is not ready for mass use anyway, IMHO 18:28:07 @rbrunner7: Not really. Large signer thresholds in the current scheme are pretty much infeasible. FROST scales logarithmically 18:28:24 It always has two DKG rounds as well 18:28:59 I can also repeat here that this standalone GUI is almost ignored to death. Why? Because multisig itself seems to be such an edge use case right now, if you ask me. 18:29:04 It's also natively designed for signer-subset flexibility, and forgery-attack mitigation is proven to be secure in FROST due to it having blinding factors 18:29:07 Certainly not because of "UI problems" 18:30:25 I think it's something many people would find very useful, if it weren't for the prohibitive usability cost of having to find some niche third-party software to use it (which is barely maintained), and first-party support for it is actively discouraged 18:31:04 This also ties into adoption. Some organizations require multisig, and simply cannot use Monero if it's not easy 18:31:22 We could probably continue to chat about this for much longer, but anyway, let's go back to this meeting. Is there any other subject somebody would like to bring up for today? 18:32:37 Maybe we also lost some members, scared them away with multisig lol 18:33:28 Thus I say let's call it a meeting for now. Thanks everybody for attending, read you again next week! 18:33:47 thanks everyone, ciao 18:35:16 Some notes I took regarding multisig (may not be 100% accurate): 18:35:16 https://paste.debian.net/hidden/3db288e8 18:35:36 It may be possible to keep legacy functionality, in the same way that legacy seeds can still be used after the introduction of Polyseed 18:36:18 Oh, I just remember now that I wanted to test your experimental multisig capable GUI wallet, totally forgot after getting exhausted working on the Polyseed PR 18:36:55 No problem, not urgent at all, haha :) 18:37:19 Working on that did remind me how much less of a nightmare FROST would be, though 💀 18:38:11 Fully agree. It's a lot of other factors, some non-technical, that make this a terrible tangle, IMHO