17:06:02 <m-relay> <r​brunner7:monero.social> Meeting in a bit less than 1 hour
18:00:01 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1273
18:00:19 <m-relay> <s​needlewoods_xmr:matrix.org> Hey
18:01:10 <m-relay> <h​into:monero.social> hello
18:01:23 <m-relay> <j​berman:monero.social> *waves*
18:02:06 <m-relay> <v​tnerd:monero.social> Hi
18:02:17 <m-relay> <r​brunner7:monero.social> Alright, on to the reports
18:02:24 <m-relay> <s​needlewoods_xmr:matrix.org> made the first tx, but rushed through the implementation, now have to fix some areas to make sure it behaves the same as before and all the command options work as expected
18:02:25 <m-relay> <s​yntheticbird:monero.social> hello
18:02:49 <m-relay> <r​brunner7:monero.social> SNeedlewoods: You mean with the CLI wallet running on Wallet API?
18:03:00 <m-relay> <s​needlewoods_xmr:matrix.org> exactly
18:03:08 <m-relay> <r​brunner7:monero.social> Nice milestone :)
18:03:47 <m-relay> <r​brunner7:monero.social> I am content that my improved peer selection PR was merged. Thanks to the reviewers. Must be my first PR for a year or so ...
18:03:55 <m-relay> <s​needlewoods_xmr:matrix.org> picked almost all the low hanging fruits and now more complex stuff is still left
18:04:29 <m-relay> <h​into:monero.social> me: thinking about how to implement PoWER with as few diffs as necessary
18:04:54 <m-relay> <v​tnerd:monero.social> Got lws server _mostly_ integrated with carrot/fcmp. Legacy and view balance keys work and pickup incoming and spends, but view-incoming doesn't fully work with subaddresses yet
18:05:10 <m-relay> <r​brunner7:monero.social> hinto: Cuprate, yes?
18:05:39 <m-relay> <j​berman:monero.social> me: announced FCMP++ & Carrot alpha stressnet v1 (https://github.com/seraphis-migration/monero/releases/tag/v0.19.0.0-alpha.1), started opening some smaller PR's from the integration to the main repo
18:06:12 <m-relay> <h​into:monero.social> for both `monerod` and `cuprated`
18:06:16 <m-relay> <r​brunner7:monero.social> Somebody should put up a nice countdown to October 3, with carrots or so
18:07:16 <m-relay> <r​brunner7:monero.social> I think we reach the point where it becomes quite improbable that the hardfork to FCMP++ will never come, like the one to Seraphis :)
18:07:56 <m-relay> <r​brunner7:monero.social> So first stressnet will still run without PoWER, obviously
18:08:05 <m-relay> <j​berman:monero.social> Yep
18:08:14 <m-relay> <r​brunner7:monero.social> Maybe a good chance to see what happens without that as protection
18:08:39 <m-relay> <k​ayabanerve:matrix.org> Hello, y'all! Congrats to everyone on the tagged network release!
18:09:06 <m-relay> <h​into:monero.social> jberman: is there any notable behavior or logs to look for when running the 0.19 binary?
18:09:42 <m-relay> <j​berman:monero.social> When you run the migration, log level 1 is fun to watch the tree roots and n leaves in the tree
18:09:53 <m-relay> <h​into:monero.social> also would the official `monerod` release be an opportunity for `v1.0.0`?: https://github.com/monero-project/meta/issues/721
18:10:28 <m-relay> <k​ayabanerve:matrix.org> I have the partially off-topic update of having been working on a new RPC client which has well-defined bounds, and how that's apparently quite difficult. Nothing from me about FCMP++ other than the comment the Helios/Selene curves will be updated.
18:10:32 <m-relay> <r​brunner7:monero.social> hinto: That's almost a heresy
18:10:34 <m-relay> <k​ayabanerve:matrix.org> (solely their constants)
18:11:04 <m-relay> <r​brunner7:monero.social> No big deal, implementation-wise, right?
18:11:42 <m-relay> <k​ayabanerve:matrix.org> No, it'll be trivial. Just updating constants in Rust, and the ones duplicated in C++ by jeffro256 if any exist.
18:12:22 <m-relay> <r​brunner7:monero.social> Helios/Selene, now even more curvy
18:12:34 <m-relay> <k​ayabanerve:matrix.org> It will be a hard fork though 😱😱😱😱 So stressnet will use the old curves until a new net is created.
18:12:56 <reverseengineer> hey
18:13:57 <m-relay> <r​brunner7:monero.social> And of course no speed difference, the code being constant-time
18:14:32 <m-relay> <k​ayabanerve:matrix.org> And because the new parameters won't involve changing any of our methodology
18:15:18 <m-relay> <k​ayabanerve:matrix.org> Oh. There may be very slight differences in the exponentiation function, used for point (de)compression, depending on the amount of bits set in the new choices of prime numbers.
18:15:35 <m-relay> <j​berman:monero.social> Something probably worth mentioning in here: I'm likely going to start working on Serai soon-ish (potentially within the next week or 2), prioritizing FCMP++/Carrot tasks such that any work I do on Serai should not delay any FCMP++/Carrot work / impact the timeline in any way
18:16:22 <m-relay> <r​brunner7:monero.social> Is that within the CCS framework, or a different "account" to pay for your Serai work?
18:16:35 <m-relay> <j​berman:monero.social> different account, completely separate from CCS
18:17:06 <m-relay> <r​brunner7:monero.social> Ok, good so now misunderstandings and complaints will crop up
18:17:49 <m-relay> <r​brunner7:monero.social> Some people on Reddit are trigger-happy with such stuff :)
18:17:59 <m-relay> <r​brunner7:monero.social> (Not that this means much)
18:18:34 <m-relay> <r​brunner7:monero.social> Alright, looks like we are through with the reports. Anything else to discuss today?
18:19:39 <m-relay> <r​brunner7:monero.social> Does not look like it. So thanks everybody for attending, read you again next week!
18:19:45 <m-relay> <s​needlewoods_xmr:matrix.org> Question about fee priority:
18:19:45 <m-relay> <s​needlewoods_xmr:matrix.org> (First a little shout-out: thanks to [this PR](https://github.com/monero-project/monero/pull/9838) the fee priority code in wallet2 is less confusing now.)
18:19:47 <m-relay> <s​needlewoods_xmr:matrix.org> Below is some common terminology that's used for the 4 different levels + a default value
18:19:49 <m-relay> <s​needlewoods_xmr:matrix.org> 0 Default
18:19:51 <m-relay> <s​needlewoods_xmr:matrix.org> 1 Unimportant / Low
18:19:53 <m-relay> <s​needlewoods_xmr:matrix.org> 2 Normal      / Medium
18:19:55 <m-relay> <s​needlewoods_xmr:matrix.org> 3 Elevated    / High
18:19:57 <m-relay> <s​needlewoods_xmr:matrix.org> 4 Priority    / Very High
18:20:00 <m-relay> <s​yntheticbird:monero.social> JIT
18:20:01 <m-relay> <s​needlewoods_xmr:matrix.org> Unfortunately the Wallet API uses a differnt term for the fifth element in the enum: `Priority_Last` ([src](https://github.com/monero-project/monero/blob/master/src/wallet/api/wallet2_api.h#L73-L79)) and I'm not sure if it is supposed to be the same as "4 / Priority / Very High". The original PR does not explain it and the GUI only uses "low", "medium" and "high" ([src](https://gi<clipped 
18:20:03 <m-relay> <s​needlewoods_xmr:matrix.org> thub.com/monero-project/monero-gui/blob/440012b454a39de860c97226e33af204ced868ec/src/libwalletqt/PendingTransaction.h#L62-L66))
18:20:15 <m-relay> <s​needlewoods_xmr:matrix.org> So my question, should I
18:20:17 <m-relay> <s​needlewoods_xmr:matrix.org> a) rename `Priority_Last` to `Priority_VeryHigh`?
18:20:19 <m-relay> <s​needlewoods_xmr:matrix.org> b) rather add `Priority_VeryHigh` as fifth element and move `Priority_Last` to the sixth? In case `Priority_Last` is used somewhere e.g. to make sure to always get the highest priority even if the enum was updated, with `Priority_Last-1`.
18:20:21 <m-relay> <s​needlewoods_xmr:matrix.org> c) do nothing?
18:20:49 <m-relay> <r​brunner7:monero.social> Will try to have a look to build an informed opinion
18:21:26 <m-relay> <s​needlewoods_xmr:matrix.org> alright thanks, nothing else to discuss for me