<dangerousfreedom:matrix.org> Hello everyone,

<dangerousfreedom:matrix.org> a second update on my project after some private discussions with kayaba. I decided to re-evaluate what I want to achieve with this project. So I believe I will only be able to give a "final first draft" by mid-end of August as I included others things that I want to try as well.

<dangerousfreedom:matrix.org> What was achieved so far:

<dangerousfreedom:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/34ix-pMLZTdFRzdZ ]

<rbrunner7> Thanks, @dangerousfreedom:matrix.org , for this detailed report.

<rbrunner7> Meeting in a bit more than 1 hour

<rbrunner7> Meeting time. Hello! monero-project/meta #1416

<sneedlewoods_xmr:matrix.org> hi

<jpk68:matrix.org> Hello

<jberman> waves

<rbrunner7> On to the reports from last week!

<rbrunner7> @dangerousfreedom:matrix.org left a report a while before this meeting, in this room. Looks like he made great progress. Not 100% what was planned, but still solid.

<sneedlewoods_xmr:matrix.org> Mostly reviews, also started to look into this (oxen-io/oxen-core #1466) refresh lock issue that selsta brought up in the last meeting, but with my limited knowledge I didn't spot any issue so far.

<jpk68:matrix.org> Me: worked on baking I2P support into the GUI, plus regular patches as normal; helped with testing Qt6 builds of the GUI

<rbrunner7> I myself did two passes through my Polyseed PR, based on review comments from 3 people (thanks to all!), and I could update with improved code.

<rbrunner7> Maybe @jeffro256:monero.social will find time for a re-review, or anybody else for a first review

<jberman> me: continuing handling upstream FCMP++ PR's, beta stressnet v2.1, and continuing finalizing investigation into sporadic observed double spends on stressnet

<rbrunner7> It's this here of course: monero-project/monero #10765

<rbrunner7> @jberman:monero.social: So these double-spends are still with you?

<rbrunner7> Seems to be a tough nut to crack :)

<jberman> @rucknium mentioned one was still observed one with a fix in place, and I haven't yet had a chance to dig into those logs. My initial take is that it's revealing multiple interconnected / related upstream bugs that only trigger on very rare occassion, that's exacerbated by stressnet

<rbrunner7> So this goes into a long row of things that broke when real pressure was applied to a Monero network ...

<rbrunner7> No "battle-tested" without any battle, lol

<jberman> essentially yes

<rbrunner7> Alright, seems that's about it regarding reports.

<rbrunner7> Do we have to discuss something this week beyond those?

<jeffro256> Howdy sorry I'm late

<rbrunner7> Right on time still to drop your report :)

<jeffro256> Not too much to report from me other then I'm still deep in reviewland

<rbrunner7> Ok, I guess that progress if you are not mostly producing more mountains of code anymore

<rbrunner7> Are any bigger programming jobs left at all on the way to FCMP++?

<rbrunner7> With emphasis on "bigger"

I opened multiple PRs in regards to our test suite that would need review in case anyone has time

<rbrunner7> On the normal Monero repo? Somehow can't see multiples

<jeffro256> @rbrunner7: Multisig, HW

<rbrunner7> Ah, no, just did not go back far enough, sorry for the false alarm

<jeffro256> hot/cold is mostly done, tx proofs are mostly done

<jeffro256> consensus code is mostly done

<jeffro256> the rest of Carrot is mostly done

<jeffro256> HW support is mostly done on the hot side, the bulk of the work left for HW support is on the HW side

<jeffro256> So for the core repo, mainly Multisig which Koe is working on

<rbrunner7> Sounds good

<jpk68:matrix.org> Does multisig require a separate audit?

<sneedlewoods_xmr:matrix.org> @rbrunner7: too slow, but I think selsta is referring to these

<sneedlewoods_xmr:matrix.org> 10818 10820 10823 10826 10844 10855

<rbrunner7> @jpk68:matrix.org: Maybe depends on the definition of "require" ... I am pessimistic that we would find the funds to do a proper audit there, but that's only MHO.

<jeffro256> @jpk68:matrix.org: If we were to audit yes

<jeffro256> AKA it's not under the scope of any currently contracted or planned audit

<rbrunner7> It's "experimental", all is good :)

<rbrunner7> Maybe we will end up using the improved Rust implementation of a much more solid multisig approach, one that does not result in 1000 messages passed back and forth if you want 7 signers or so ....

<rbrunner7> Alright, looks like we are through for today. Thanks everybody for attending, read you again next week!

<sneedlewoods_xmr:matrix.org> thanks everyone, cu

<jeffro256> Thanks everyone !

<jpk68:matrix.org> Thanks :))

<rbrunner7> I think I actually did 7 signers once, to stress-test the MMS, and it did go up into the hundreds of messages exchanged before all the keys were established

<jeffro256> Yeah, thankfully FROST doesn't have exponentially big signings / setup ceremonies

<jeffro256> Ande that's what Kayaba implemented for FCMP++ SA/L multisig in the Rust lib, amongst other things

multisig is mostly done, just has some wallet2 issues blocking the test

on pause while I slowly review other things