16:56:23 <m-relay_> <r​brunner7:monero.social> Meeting in a bit more than 1 hour
18:00:01 <m-relay_> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1282
18:00:28 <m-relay_> <s​needlewoods_xmr:matrix.org> Hi
18:01:17 <m-relay_> <j​berman:monero.social> *waves*
18:02:13 <m-relay_> <j​effro256:monero.social> Howdy
18:02:34 <m-relay_> <r​brunner7:monero.social> Alright, let's start with the reports about last week
18:02:39 <m-relay_> <s​needlewoods_xmr:matrix.org> `m_wallet` is no more, now working on `tools::wallet2`, ~25 of those are left, but they boil down to just a few TODOs (e.g. there are several calls to `tools::wallet2::parse_*_payment_id()` and `accept_loaded_tx()` functions which rely on `tools::wallet2::tx_construction_data`, need to figure out a replacement for that)
18:02:48 <m-relay_> <s​needlewoods_xmr:matrix.org> I didn't come up with a satisfying solution for `--generate-from-json` [src](https://github.com/monero-project/monero/blob/d32b5bfe18e2f5b979fa8dc3a8966c76159ca722/src/simplewallet/simplewallet.cpp#L4428), yet. It's also used by [RPC](https://github.com/monero-project/monero/blob/d32b5bfe18e2f5b979fa8dc3a8966c76159ca722/src/wallet/wallet_rpc_server.cpp#L4999) so I think it should <clip
18:02:49 <m-relay_> <s​needlewoods_xmr:matrix.org> be supported by the Wallet API.
18:02:52 <m-relay_> <s​needlewoods_xmr:matrix.org> With the GUI, under some conditions I was able to get the daemon blockchain height on wallet creation, but it's fragile and it doesn't work for one of the most important cases, when someone is trying to create a new wallet for the very first time. Will do further investigation.
18:03:23 <m-relay_> <r​brunner7:monero.social> "m_wallet is no more" Wow!
18:03:29 <m-relay_> <r​brunner7:monero.social> Quite a milestome
18:03:54 <m-relay_> <s​needlewoods_xmr:matrix.org> it felt a little unreal when it compiled
18:05:27 <m-relay_> <r​brunner7:monero.social> Good that you investigate that GUI wallet creation issue
18:07:18 <m-relay_> <j​berman:monero.social> We released v1.2 alpha stressnet, worked on another p2p change here that I ended up closing based on discussion (https://github.com/seraphis-migration/monero/pull/174), fixed a synchronization issue that was causing FCMP++ tx construction failures in the GUI (https://github.com/seraphis-migration/monero/pull/183), continuing toward 1.3 alpha stressnet, reviewed jeffro's upstream P<clipped me
18:07:19 <m-relay_> <j​berman:monero.social> R to cache input verification results
18:09:18 <m-relay_> <r​brunner7:monero.social> Is 183 a long undetected edge case present also in the current release software?
18:10:58 <m-relay_> <j​effro256:monero.social> Reviewing j-berman's PRs to FCMP++ and currently writing more unit tests for the mempool validation cache upstream PR
18:11:08 <m-relay_> <j​berman:monero.social> Yes, one reason it doesn't affect current release is because ring sigs don't work the same as the tree (ring members will be static even as you add a block to the chain, whereas the usable tree in FCMP++ advances)
18:12:17 <m-relay_> <j​berman:monero.social> Plus FCMP++ tx construction takes a lot longer
18:13:06 <m-relay_> <r​brunner7:monero.social> I see. Are there significant speedups still ahead, or do large txs just take their time with FCMP++?
18:14:42 <m-relay_> <j​berman:monero.social> There may be room for further multithreading, plus assembly in curve arithmetic. kayabanerve would have a better idea
18:14:58 <m-relay_> <j​berman:monero.social> But nothing planned at the moment
18:15:30 <m-relay_> <r​brunner7:monero.social> Ah, ok, so not a case where something is still waiting to to online, like some contest results
18:16:33 <m-relay_> <j​berman:monero.social> There's the switch to dalek ed25519 that's still pending, but aside from that, no. I don't recall how much that would be expected to affect tx construction times. The flamegraphs showed
18:17:25 <m-relay_> <r​brunner7:monero.social> I guess many more things are more pressing than that :) Maybe currently just makes spamming a bit harder than before.
18:18:36 <m-relay_> <r​brunner7:monero.social> I wonder a bit how long the fee algorithm discussion might still go forth and back in the MRL meetings. At some point in time, decisions must come, so somebody can put them into code, right?
18:19:04 <m-relay_> <j​berman:monero.social> Yes, I have a simplified proposal I intend to share soonish too
18:20:01 <m-relay_> <r​brunner7:monero.social> Maybe we will reach the long-sought "loose consensus" with that, who knows.
18:20:21 <m-relay_> <r​brunner7:monero.social> Looks like that's it for the reports. Anything further to discuss today?
18:21:13 <m-relay_> <r​brunner7:monero.social> Everybody very busy with coding anyway :)
18:22:22 <m-relay_> <j​berman:monero.social> Thank you for your review on 162 also :)
18:22:59 <m-relay_> <r​brunner7:monero.social> Welcome! Not much is left where I can still contribute something code-wise right now, frankly.
18:23:31 <m-relay_> <r​brunner7:monero.social> Alright, looks like we are through. Thanks everybody for attending, read you again next week!
18:23:57 <m-relay_> <s​needlewoods_xmr:matrix.org> Thank you
20:59:30 <m-relay_> <j​effro256:monero.social> I think that this *does* affect the GUI since refreshing potentially modifies `m_transfers`, but it's just that those edits probably happen very quickly, so the likelihood that it causes reproducible problems is close to 0%
21:41:03 <m-relay_> <j​berman:monero.social> Right I meant "yes" as in it is an existing issue in the GUI, but those were reasons it hasn't been observed to cause issues
22:28:36 <m-relay_> <j​effro256:monero.social> Ah I see