<rbrunner7> Meeting in 1 hour

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

<sneedlewoods_xmr:matrix.org> hello

<vtnerd> Hi

<tobtoht> Hi

<jberman> waves

<rbrunner7> Alright, what are the reports since last week?

<tobtoht> The release-v0.19 branch is live.

<sneedlewoods_xmr:matrix.org> Updated the wallet-rpc PR, it now has a switch to translate extended Wallet API error codes into wallet-rpc error codes without assuming they're the same.

<rbrunner7> I started to work on Polyseed for the Monero GUI wallet

<sneedlewoods_xmr:matrix.org> Also looked into the issue where creating many subaddresses is really slow (mentioned by DataHoarder in last MRL meeting), especially when subaddress lookahead was modified.

<sneedlewoods_xmr:matrix.org> e.g. in the cli address mnew 1000

<sneedlewoods_xmr:matrix.org> I did a thing, and it became so fast that I assume I did something wrong. But after some testing and debugging it seems to work. Before I make a PR you can have a look here (there has to be an issue with this approach, it can't be that easy, right? :D) github.com/monero-project/monero/co…wallet:x_add_subaddress_performance

<sneedlewoods_xmr:matrix.org> Testing data: Number of seconds until address mnew 1000 on a fresh wallet is finished

<sneedlewoods_xmr:matrix.org> 1. 2.

<sneedlewoods_xmr:matrix.org> Before: 4 45[... more lines follow, see mrelay.p2pool.observer/e/lcGnkp0LUmZ3emFt ]

<tobtoht> @tobtoht: All FCMP++ / Carrot related changes can now go into master.

<tobtoht> Fixes, polyseed, and tx relay v2 will be backported to release-v0.19: monero-project/monero #11015

<tobtoht> A final v0.18 release is planned: monero-project/monero #11009

<tobtoht> After the v0.18 release, focus will be on working towards tagging v0.19.0.0.

sneedlewoods: I found the issue also compounded later when scanning outputs

<rbrunner7> "The release-v0.19 branch is live." So from now on it's one PR for master and one for that new 0.19 branch?

<jeffro256> Howdy

<jpk68:matrix.org> Hello

<jberman> Dug into @Rucknium 's logs for the wallet rejection double spend issue and assessed tx relay v2 issues, implemented some solid changes to tx relay v2 as a result (and after discussion with selsta and boog) : seraphis-migration/monero #450

<jpk68:matrix.org> Me: made some hardware wallet fixes, polishing I2P SAM code, regular patches, etc.

<jeffro256> @tobtoht: Backporting these features is a good idea since their development graph will be a lot less crazy than Carrot/FCMP

<jeffro256> And we can proceed with FCMP merges ;)

rbrunner7: you don't need to open a separate release-v0.19 PR for now, we have one large backport PR

<tobtoht> @rbrunner7: We have adopted bulk backports temporarily to reduce workload as we try to coordinate three active branches. I think it would be easiest for us to handle if fixes are submitted against master only for now. After a fix is merged to master it will be added to the backports PR.

<rbrunner7> Ah, I see. Exciting, a new approach :)

<tobtoht> @jeffro256: The first build system changes are making their way in :)

<rbrunner7> Is anything along these lines planned for the GUI wallet as well?

<rbrunner7> Or isn't the PR "traffic" there too small?

we don't do branches there

<rbrunner7> *Or is

<rbrunner7> Ok. If I have good luck and will be fast with Polyseed for GUI, it might need to wait for the submoduled Monero to catch up then ...

I already have a wip branch for Polyseed added to GUI

<rbrunner7> Ah, you mean you work on it?

I was asking gbks for a new seed template but he did not reply so far

yes

it's not polished yet

<rbrunner7> Ok, so I guess you go first :)

<jeffro256> FWIW, with Carrot/FCMP++, there are almost 0 changes that downstream projects like the GUI wallet need to adopt due to downstream changes, besides relevant UX changes added by GUI in the first place. So the GUI can basically "ignore" the Carrot/FCMP++ changes until they are ready to update ring-specific UX stuff

<jeffro256> *due to upstream changes

<rbrunner7> selsta: What do you mean with "new seed template"?

PDF template to print and write down seed words

the current one has 25 words

<rbrunner7> Ah, ok

<jpk68:matrix.org> That HTML document that comes with the Windows install might be rendered (even more) irrelevant after :(

<rbrunner7> You mean the ReadMe?

<rbrunner7> Don't insult my beautiful ReadMe :)

<rbrunner7> Maybe it could use some love, like so many thing in Monero software land ...

<jpk68:matrix.org> Not the README.md, the other thing

<rbrunner7> Yeah, that's the ReadMe for the users.

<rbrunner7> That "other thing"

<rbrunner7> Alright, seems like the time plan of @jeffro256:monero.social that we discussed quite extensively in our meeting last week sailed through the MRL meeting without problems, so I guess we will go for that?

<rbrunner7> Waiting for the starting shot, the start of the countdown to hardfork :)

<rbrunner7> Seems we are through with the reports. Do we have something to discuss beyond those?

<jberman> I briefly discussed this with boog: those changes to tx relay v2 I linked above maximally benefit from all nodes on the stress network running it, so it may be the move to bump to beta stressnet v3 if we want those changes in and want to test them best

<jberman> just noting that as a potential consideration for the future once those changes get reviewed in more detail

<rbrunner7> You would force all nodes to the new version with this approach, to achieve optimal testing conditions?

<jberman> essentially yes

<rbrunner7> I guess testing this fundamental thing well is a rather good idea

<rbrunner7> Is there any hesitation about "wanting those changes in"?

<rbrunner7> Waiting for review and feedback I guess

<jberman> @rbrunner7: yep

<rbrunner7> Let a thousand LLMs pick it apart

<tobtoht> Oh, I finally figured out where the horizontal scroll bar is. I had just extended my browser window to 6k pixels. Plan seems good to me. > <@rbrunner7> Alright, seems like the time plan of @jeffro256:monero.social that we discussed quite extensively in our meeting last week sailed through the MRL meeting without problems, so I guess we will go for that?

<rbrunner7> Exactly, scrolling that thing is an intelligence test

<rbrunner7> Ok, seems we are through for today. Thanks everybody for attending, read you again next week!

<sneedlewoods_xmr:matrix.org> thanks everyone, cu

I am testing your patch sneedlewoods on some of the stressnet ones, let's see :)

<sneedlewoods_xmr:matrix.org> great :) good luck, haven't tested with a wallet that owns enotes, so interested to see if it helps there too (even though I doubt it)

nothing to report, I review stuff as it comes my way

sneedlewoods_xmr: still only decoding about 2 outputs/second, when it gets to blocks with many of the wallet outputs (multiple outputs per block), bottlenecked by single thread perf on map code

--testnet --subaddress-lookahead 10000:100 and gave it a few view keys from the stressnet spam wallets

<sneedlewoods_xmr:matrix.org> Thanks for checking, will try to further investigate during the week