<r​brunner7:monero.social> Meeting in a bit less than 1 hour

👍

<s​yntheticbird:monero.social> What if I don't want the meeting to happen ?

<s​yntheticbird:monero.social> I refuse

<s​yntheticbird:monero.social> You will not coordinate to make monero better

<s​yntheticbird:monero.social> I won't let it happen

<i​ntr:unredacted.org> you'll meet your maker

<r​brunner7:monero.social> Well, how many XMR do you pay me to cancel the meeting? You still have 20 minutes to place an offer.

<r​brunner7:monero.social> Soon we will need no meetings anymore anyway. A small group of LLM supported vibe coders will run the show, and we can wait in peace for Monero to moon and then retire.

<s​yntheticbird:monero.social> I'll pay the sum of 51+90i XMR

<r​brunner7:monero.social> Is that a complex number?

<s​yntheticbird:monero.social> yes

<s​yntheticbird:monero.social> you don't want complex moneros?

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1338

<j​berman:monero.social> *waves*

<s​needlewoods_xmr:matrix.org> Hello

<s​yntheticbird:monero.social> Hi

<r​brunner7:monero.social> Something administrative first: Ok for you people to skip next Monday's February 16 meeting, because of Monerotopia, and meet again in 2 weeks?

<s​needlewoods_xmr:matrix.org> I'm fine with that

<r​brunner7:monero.social> Ok, if nobody contradicts still, I will schedule that way.

<r​brunner7:monero.social> On to the reports - what happened last week?

<s​needlewoods_xmr:matrix.org> Started with `/transfer*`/`/sweep*` commands, now trying to figure out how to get the necessary information for `cryptonote::tx_construction_data` from `UnsignedTransaction` and `PendingTransaction` needed in `/describe_transfers`

<r​brunner7:monero.social> In the RPC server, right?

<j​effro256:monero.social> Howdy

<s​needlewoods_xmr:matrix.org> wallet_rpc_server, yes

<j​berman:monero.social> me: some PR followup, set up a 4-phase plan to get the FCMP++ integration audited, got pre-fork multisig working / tests passing

<r​brunner7:monero.social> What do you mean with "pre-fork multisig"? Does that need to "get it working again"?

<j​berman:monero.social> Ya it was borked upon integrating the curve tree sync into wallet2

<j​berman:monero.social> I can expand a bit further on that

<r​brunner7:monero.social> As an unintended side effect I hope :)

<j​berman:monero.social> So the current multisig requires all multisig participants collaborate to generate key images for received outputs

<j​berman:monero.social> Thus, in order to determine if an output has been spent, the current impl will re-sync a wallet upon generating received output key images. aka receive output in block n, if the multisig wallet has synced to block n+10,000, then the multisig participants collaborate to generate the received output's key image, then all their wallets will re-sync the wallet starting from block n

<j​berman:monero.social> the problem is: upon introducing the curve tree sync into wallet2, the wallet can't re-sync past a max of 100 blocks by default, otherwise it needs to re-sync from its restore height

<j​berman:monero.social> So after discussing this with jeffro256 , who recognized that technically the wallet doesn't need to re-sync in this case, I ended up reusing the "backgound sync" implementation for multisig sync, so that upon identifying the receive output in block n, the multisig wallet will then sync all possible spends of that output going forward too, so that when generating the key image lat<clipped messag

<j​berman:monero.social> er, it can process the "background sync cache" to identify spent key images if there were any

<j​berman:monero.social> that way the multisig wallet doesn't have to re-sync as it currently does

<j​berman:monero.social> we've known this part of multisig has been broken since the curve tree sync was introduced fwiw, it's been on the TODO list / a FIXME was in the code too

<j​berman:monero.social> Can see this PR gets rid fo the FIXME: seraphis-migration/monero #291/changes

<j​berman:monero.social> in wallet2 line 15041

<r​brunner7:monero.social> Interesting. I would have guessed it's just a question of ignoring that 100 blocks limit for such cases, but I am sure that's because I don't know enough about the actual issues.

<j​berman:monero.social> if you recall how the wallet now builds the tree locally, the wallet throws away data from the tree that's older than 100 blocks that it doesn't need

<j​berman:monero.social> otherwise it has to keep the multi GB tree cached locally

<r​brunner7:monero.social> Yeah, but pre-fork there is no tree yet, no?

<r​brunner7:monero.social> Ah, also post-fork the multisig transactions can come in later than 100 blocks

<j​berman:monero.social> good q. the updated wallets are currently set up to re-sync from their restore height, and start building the tree, so that when the fork comes, they can spend outputs received before the fork with the FCMP++ proof

<j​berman:monero.social> this change is necessary to ensure that multisig wallets correctly maintain the tree for when the fork does occur

<j​berman:monero.social> and that too

<j​effro256:monero.social> Yeah I think a similar background sync technique could be employed for multsig by saving all txs with rings with ring members that we own , it just hasn't been done yet

<j​berman:monero.social> yep that's what that PR does :)

<r​brunner7:monero.social> Ok. Usually if the remaining issues get complex fast, like it seems to happen here, it means that the end is almost there, with "end" meaning "working".

<j​berman:monero.social> what's now "working" is pre-fork multisig with an FCMP++/Carrot compatible wallet. What's not yet working, and is going to be a fairly significant lift to get working, is FCMP++/Carrot multisig

<r​brunner7:monero.social> Ok. Will you implement that, jberman ?

<j​berman:monero.social> I started looking into it and it's a pretty major can of worms, I'm not sure yet. I think it will be a bridge that we'll have to cross soon enough though

<r​brunner7:monero.social> Sounds like it :)

<r​brunner7:monero.social> Alright, if we are through with the reports, anything beyond that to discuss today?

<r​brunner7:monero.social> Don't do anything unwise when re-entering the US coming from Mexico after Monerotopia perhaps ...

<s​needlewoods_xmr:matrix.org> In regards to stressnet, AFAICT v1.6 is running very smoothly, the network is currently beeing stressed with ~650MB in tx pool and 887 blocks backlog and monerod is using ~1.5GB memory

<s​needlewoods_xmr:matrix.org> and I hope everyone going to MoneroTopia is having a great time, I'm excited for the virtual conference

<r​brunner7:monero.social> I second that, live the good life at that conference. I think we can close, thanks everybody for attending, read you again in **two** weeks.

<s​needlewoods_xmr:matrix.org> thanks everyone, cu

<s​yntheticbird:monero.social> thanks, very tasteful meeting

<j​berman:monero.social> thank you!

<j​effro256:monero.social> Ah I see. Is the significant lift for FCMP++/Carrot the fact that ring members don't exist ?

<j​effro256:monero.social> You should be able to save all txs with at least one scannable output, and that should capture everything since that's a rule in the Carrot code

<j​berman:monero.social> no the whole tree sync part should be good to go now. the significant lift is going to be constructing the SAL proof I think

<j​effro256:monero.social> Oh yeah, that part does need a lot of new crypto

<j​effro256:monero.social> IIRC kayaba said that they wrote a Rust lib for multisig SA/L proving used Carrot-derived addresses

<j​effro256:monero.social> Which is awesome

<j​effro256:monero.social> And it should be usable for non-Carrot-derived wallets too

<j​berman:monero.social> github.com/monero-oxide/monero-oxid…mp%2B%2B/src/sal/legacy_multisig.rs

<j​effro256:monero.social> If we keep the same legacy multisig API, I think that it can be fairly simple to upgrade the SA/L proving

<j​effro256:monero.social> Since you've already handled the tree syncing part

<j​berman:monero.social> kayaba also wrote up this guide on dropping in the rust impl into the wallet2: gist.github.com/kayabaNerve/3b2c648c623bc4ce4ca288725428ea76

<j​berman:monero.social> and that was applicable for clsag

<j​effro256:monero.social> A *really* big rework would be necessary to handle multisig coordination without partial key images

<j​effro256:monero.social> But I think that we can activate the HF without support for the new multisig API

<j​berman:monero.social> I think so long as multisig wallets that were created before the fork can spend after the fork, then that's ok for the fork