-
m-relay_
<rbrunner7:monero.social> Meeting in a bit more than 1 hour
-
m-relay_
<rbrunner7:monero.social> Meeting time. Hello!
monero-project/meta #1282
-
m-relay_
<sneedlewoods_xmr:matrix.org> Hi
-
m-relay_
<jberman:monero.social> *waves*
-
m-relay_
<jeffro256:monero.social> Howdy
-
m-relay_
<rbrunner7:monero.social> Alright, let's start with the reports about last week
-
m-relay_
<sneedlewoods_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)
-
m-relay_
<sneedlewoods_xmr:matrix.org> I didn't come up with a satisfying solution for `--generate-from-json` [src](
github.com/monero-project/monero/bl…simplewallet/simplewallet.cpp#L4428), yet. It's also used by [RPC](
github.com/monero-project/monero/bl…/wallet/wallet_rpc_server.cpp#L4999) so I think it should <clip
-
m-relay_
<sneedlewoods_xmr:matrix.org> be supported by the Wallet API.
-
m-relay_
<sneedlewoods_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.
-
m-relay_
<rbrunner7:monero.social> "m_wallet is no more" Wow!
-
m-relay_
<rbrunner7:monero.social> Quite a milestome
-
m-relay_
<sneedlewoods_xmr:matrix.org> it felt a little unreal when it compiled
-
m-relay_
<rbrunner7:monero.social> Good that you investigate that GUI wallet creation issue
-
m-relay_
<jberman:monero.social> We released v1.2 alpha stressnet, worked on another p2p change here that I ended up closing based on discussion (
seraphis-migration/monero #174), fixed a synchronization issue that was causing FCMP++ tx construction failures in the GUI (
seraphis-migration/monero #183), continuing toward 1.3 alpha stressnet, reviewed jeffro's upstream P<clipped me
-
m-relay_
<jberman:monero.social> R to cache input verification results
-
m-relay_
<rbrunner7:monero.social> Is 183 a long undetected edge case present also in the current release software?
-
m-relay_
<jeffro256:monero.social> Reviewing j-berman's PRs to FCMP++ and currently writing more unit tests for the mempool validation cache upstream PR
-
m-relay_
<jberman: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)
-
m-relay_
<jberman:monero.social> Plus FCMP++ tx construction takes a lot longer
-
m-relay_
<rbrunner7:monero.social> I see. Are there significant speedups still ahead, or do large txs just take their time with FCMP++?
-
m-relay_
<jberman:monero.social> There may be room for further multithreading, plus assembly in curve arithmetic. kayabanerve would have a better idea
-
m-relay_
<jberman:monero.social> But nothing planned at the moment
-
m-relay_
<rbrunner7:monero.social> Ah, ok, so not a case where something is still waiting to to online, like some contest results
-
m-relay_
<jberman: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
-
m-relay_
<rbrunner7:monero.social> I guess many more things are more pressing than that :) Maybe currently just makes spamming a bit harder than before.
-
m-relay_
<rbrunner7: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?
-
m-relay_
<jberman:monero.social> Yes, I have a simplified proposal I intend to share soonish too
-
m-relay_
<rbrunner7:monero.social> Maybe we will reach the long-sought "loose consensus" with that, who knows.
-
m-relay_
<rbrunner7:monero.social> Looks like that's it for the reports. Anything further to discuss today?
-
m-relay_
<rbrunner7:monero.social> Everybody very busy with coding anyway :)
-
m-relay_
<jberman:monero.social> Thank you for your review on 162 also :)
-
m-relay_
<rbrunner7:monero.social> Welcome! Not much is left where I can still contribute something code-wise right now, frankly.
-
m-relay_
<rbrunner7:monero.social> Alright, looks like we are through. Thanks everybody for attending, read you again next week!
-
m-relay_
<sneedlewoods_xmr:matrix.org> Thank you
-
m-relay_
<jeffro256: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%
-
m-relay_
<jberman: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
-
m-relay_
<jeffro256:monero.social> Ah I see