15:03:09
rucknium:
MRL meeting in this room in two hours.
17:00:51
rucknium:
Meeting time! https://github.com/monero-project/meta/issues/1346
17:00:54
rucknium:
1. Greetings
17:02:01
jberman:
waves
17:02:08
gingeropolous:
hi
17:03:30
rucknium:
2. Updates. What is everyone working on?
17:04:18
articmine:
Hi
17:04:39
gingeropolous:
monerosim is at a point where i think its done. It could probably use some more user-friendly polish, but i've run multiple runs of the 1k simulation. I'm open to suggestions on how to verify this to complete my CCS milestone.
17:05:33
rucknium:
@gingeropolous:monero.social: Great! What kind of output does it produce?
17:05:34
jberman:
me: continuing final tasks in prep for beginning the FCMP++ integration audit (this PR contains the last major items: https://github.com/seraphis-migration/monero/pull/286 ), and reviewing @jeffro256's FCMP++ scaling PR in prep for beta: https://github.com/seraphis-migration/monero/pull/282
17:07:22
gingeropolous:
Well, at the base level, the logs from all of the monerod processes and the wallets are created. There's also an analysis function that parses all of these logs and analyzes them, but the analysis portion is still very early, and because i'm no statistician i can't speak to their validity.
17:08:04
gingeropolous:
but really, just imagine you can create a network from scratch that produces logs from all of the monerods in the network of 1k nodes.. that you then have direct access to. One of the analyses I like is extracting the dandelion stem path.
17:09:04
rucknium:
Later, could you point me where to find the logs and the early analysis on the MRL research computing server? I could start to verify the output there.
17:09:25
gingeropolous:
yeah, sounds good. thanks!
17:10:02
rucknium:
3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294).
17:11:50
jberman:
I'm working on finalizing FCMP++ integration code in this PR https://github.com/seraphis-migration/monero/pull/286 , and once that's settled, will open the final 2 upstream PR's from "Audit 1: Crypto" (torsion clearing and ed25519 -> wei conversion)
17:13:07
jberman:
Then will move forward with audit plans and CCS fundraising. I'm still thinking of doing a 4-phase audit, and 1 CCS proposal that raises what should be enough to cover all phases similar to how we've done it for FCMP++ audits
17:15:06
jberman:
Also of note, I opened this upstream PR for the key image generator and unbiased/ biased hash-to-point yesterday (intended to be in scope for Audit 1: Crypto): https://github.com/monero-project/monero/pull/10338
17:17:54
rucknium:
Anything more on this agenda item?
17:18:04
jberman:
nothing from me
17:18:52
rucknium:
4. carrot-core implementation audit (https://github.com/cypherstack/carrot_core-audit).
17:19:39
rucknium:
Last meeting, this audit has just been published. Does anyone have comments or questions after digesting it?
17:20:56
jberman:
Haven't had the chance to digest yet on my end. Will do so asap
17:22:41
rucknium:
5. FCMP alpha stressnet (https://monero.town/post/6763165).
17:24:42
jberman:
The latest alpha generally seems to be running smooth judging by the lack of complaints in the stressnet channel. The latest commentary in the channel looks related to something with LWS, possibly ZMQ in monerod, but haven't dug much into it myself
17:25:10
vtnerd:
Damnit forgot this again, here now
17:26:16
vtnerd:
Yes I'm going to try to identify the xmr chat issue over the next couple of days. It's difficult to diagnose as missed mempool txes could be dropped in several places
17:29:59
rucknium:
Anything else on stressnet?
17:31:15
jberman:
Nothing from me
17:32:17
rucknium:
We can end the meeting here. Thanks everyone.
17:32:58
articmine:
Thanks
17:34:17
vtnerd:
I'll give an update since I missed it earlier. I've been working on lws web socket "push" which gives a real time mempool and block feed to clients. It should be less load on server as there's no polling after initial setup, just keep alive pings and small messages. Got some initial unit tests and its looking good
17:35:15
vtnerd:
The initial sync should be faster too as it will have better subaddress support in the API and supports magpack which is a few ticks faster with all the binary data
17:35:24
vtnerd:
*msgpack