<rbrunner7> Meeting in a bit more than 1 hour

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

Hello

<sneedlewoods_xmr:matrix.org> hey

<ack-j:matrix.org> Hi

<rbrunner7> Alright, any reports since last meeting?

hi

<jberman> waves

<jeffro256> Howdy

<sneedlewoods_xmr:matrix.org> reviews, review comments and some more investigation into the slow sync with large subaddress lookahead

<rbrunner7> Not much from me, waiting for some more review activity on my Polyseed PR ...

<sneedlewoods_xmr:matrix.org> @rbrunner7: Noted

<jberman> mostly PR's from stressnet / improvements to monerod where notable

Me: reviewed some PRs, investigated ways to improve wallet sync times (which resulted in some findings, see #11063), regular stuff

<rbrunner7> I try now to sync stressnet to help later with multisig testing and noticed that this will take my notebook literally days ... where are the stressnet checkpoints :)

<jeffro256> me: lots of PR review

<jberman> I lean in favor of just starting a new beta v3 at this point that includes the latest round of changes to tx relay v2, to alleviate disk space reqs for stressnet participants

<rbrunner7> Well, if that gains loose consensus today I can relieve my poor notebook today still

<jeffro256> Yeah, we could start the v3 with a min block size equal to or greater than currently realized block sizes

<jeffro256> To remove the warm-up period

<rbrunner7> It's not only the disk space, as I said it's also the verifying of all those large blocks

<jberman> I'm definitely a nack on messing with block size stuff further hah, last time we tried that was not fun

<rbrunner7> What do you mean with "min blocksize"?

<rbrunner7> The threshold when some fee changes kick in?

<jeffro256> We already change the min block size for FCMP++ though, it would be a single-line config change

<jeffro256> To a line we already change

<jeffro256> By min block size, I mean the penalty free zone

<jeffro256> That's what it's called in the code, which is a bad name IMO

<jeffro256> I don't mean actually putting a hard minimum on the block weight

<rbrunner7> I guess if @jberman:monero.social and @jeffro256:monero.social agree to start over then stressnet V2 is history quite soon?

<tobtoht> (news from the front: 9440 merged, sets way for 10359)

<jberman> raising penalty free zone doesn't sound terrible to me actually, fair rebuttal

tobtoht: Does that one need anything else before merge?

<jeffro256> It has approvals from Ukoe and I

<jberman> @rbrunner7: still pending on seraphis-migration/monero #450

<jeffro256> Anything that j-berman wants to add to 10359?

<jeffro256> That would be good to get out of the way so that we can start chugging on the other FCMP++ PRs

<jberman> @jeffro256: nothing planned on my end

<tobtoht> jpk68: Just a rebase and a 4 line diff to activate Guix rust machinery for CI.

<jeffro256> AFAICT discussions mainly revolved around Rust integration in general, not anything specific to the Rust FFI in that PR

+1

<jberman> @tobtoht: oh yes, sorry will do that asap

<rbrunner7> Well, the "Rust ship" has sailed. People who don't agree on fundamental grounds probably have to stay on the old chain ...

<rbrunner7> At least building is no problem, just a compiler more that is involved, as it looks from the outside. But of course lots and lots of library stuff drawn in.

<rbrunner7> Ok, looks that's it about the reports. Anything to discuss today beyond those?

<rbrunner7> Does not look like it. Thanks for attending everybody, read you again in 1 week!

Thanks, everyone :))

<sneedlewoods_xmr:matrix.org> Thanks everyone

Jinx!

<rbrunner7> "9% of total synced, estimated 1.7 days left" Hmm. A stressnet V3 would restart at current testnet height I guess?

<jeffro256> Yes

<jeffro256> @kayabanerve:matrix.org: another nudge on monero-oxide/monero-oxide #187 and monero-oxide/monero-oxide #188 now that monero-oxide/monero-oxide #191 has been merged for 10 days

20:06:46 <br-m> <jberman> I lean in favor of just starting a new beta v3 at this point that includes the latest round of changes to tx relay v2, to alleviate disk space reqs for stressnet participants

+1 from me, I am running my stressnet explorer from a remote RPC due to size, and a few changes that live on staging could also be introduced (including the double-spend fix during the waiting period)

<jeffro256> The tx output serialization was changed on fcmp++-stage, which is a hard fork change

yeah, so it'd be on v3?

10359 docker fails jberman

oh let me fix that

<ofrnxmr> +1 (and new rebase to latest master?) > <@jberman> I lean in favor of just starting a new beta v3 at this point that includes the latest round of changes to tx relay v2, to alleviate disk space reqs for stressnet participants