17:05:55 Meeting in a bit less than 1 hour 17:06:30 👍 17:28:14 What if I don't want the meeting to happen ? 17:28:23 I refuse 17:28:29 You will not coordinate to make monero better 17:28:31 I won't let it happen 17:29:07 you'll meet your maker 17:42:17 Well, how many XMR do you pay me to cancel the meeting? You still have 20 minutes to place an offer. 17:50:28 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. 17:50:49 I'll pay the sum of 51+90i XMR 17:51:16 Is that a complex number? 17:51:35 yes 17:51:38 you don't want complex moneros? 18:00:02 Meeting time. Hello! https://github.com/monero-project/meta/issues/1338 18:00:25 *waves* 18:00:36 Hello 18:00:55 Hi 18:02:16 Something administrative first: Ok for you people to skip next Monday's February 16 meeting, because of Monerotopia, and meet again in 2 weeks? 18:02:54 I'm fine with that 18:04:19 Ok, if nobody contradicts still, I will schedule that way. 18:04:27 On to the reports - what happened last week? 18:04:42 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` 18:05:09 In the RPC server, right? 18:05:28 Howdy 18:05:38 wallet_rpc_server, yes 18:07:03 me: some PR followup, set up a 4-phase plan to get the FCMP++ integration audited, got pre-fork multisig working / tests passing 18:07:50 What do you mean with "pre-fork multisig"? Does that need to "get it working again"? 18:08:21 Ya it was borked upon integrating the curve tree sync into wallet2 18:08:39 I can expand a bit further on that 18:08:40 As an unintended side effect I hope :) 18:09:30 So the current multisig requires all multisig participants collaborate to generate key images for received outputs 18:11:16 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 18:12:19 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 18:14:19 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 er, it can process the "background sync cache" to identify spent key images if there were any 18:14:36 that way the multisig wallet doesn't have to re-sync as it currently does 18:15:27 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 18:15:46 Can see this PR gets rid fo the FIXME: https://github.com/seraphis-migration/monero/pull/291/changes 18:16:02 in wallet2 line 15041 18:16:37 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. 18:17:48 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 18:18:00 otherwise it has to keep the multi GB tree cached locally 18:18:22 Yeah, but pre-fork there is no tree yet, no? 18:19:08 Ah, also post-fork the multisig transactions can come in later than 100 blocks 18:19:26 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 18:20:01 this change is necessary to ensure that multisig wallets correctly maintain the tree for when the fork does occur 18:20:51 and that too 18:21:05 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 18:21:32 yep that's what that PR does :) 18:23:06 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". 18:24:23 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 18:25:04 Ok. Will you implement that, jberman ? 18:26:22 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 18:27:04 Sounds like it :) 18:27:31 Alright, if we are through with the reports, anything beyond that to discuss today? 18:28:05 Don't do anything unwise when re-entering the US coming from Mexico after Monerotopia perhaps ... 18:28:42 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 18:28:49 and I hope everyone going to MoneroTopia is having a great time, I'm excited for the virtual conference 18:30:34 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. 18:30:57 thanks everyone, cu 18:31:11 thanks, very tasteful meeting 18:32:35 thank you! 18:33:34 Ah I see. Is the significant lift for FCMP++/Carrot the fact that ring members don't exist ? 18:34:14 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 18:34:24 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 18:35:20 Oh yeah, that part does need a lot of new crypto 18:36:01 IIRC kayaba said that they wrote a Rust lib for multisig SA/L proving used Carrot-derived addresses 18:36:09 Which is awesome 18:36:30 And it should be usable for non-Carrot-derived wallets too 18:37:04 https://github.com/monero-oxide/monero-oxide/blob/92af05e0d44bd1ec1fed6028a8d2aade615f805a/monero-oxide/ringct/fcmp%2B%2B/src/sal/legacy_multisig.rs 18:37:29 If we keep the same legacy multisig API, I think that it can be fairly simple to upgrade the SA/L proving 18:37:48 Since you've already handled the tree syncing part 18:38:26 kayaba also wrote up this guide on dropping in the rust impl into the wallet2: https://gist.github.com/kayabaNerve/3b2c648c623bc4ce4ca288725428ea76 18:38:37 and that was applicable for clsag 18:38:39 A *really* big rework would be necessary to handle multisig coordination without partial key images 18:39:24 But I think that we can activate the HF without support for the new multisig API 18:40:12 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