<r​brunner7:monero.social> Meeting in a bit less than 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1273

<s​needlewoods_xmr:matrix.org> Hey

<h​into:monero.social> hello

<j​berman:monero.social> *waves*

<v​tnerd:monero.social> Hi

<r​brunner7:monero.social> Alright, on to the reports

<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

<s​yntheticbird:monero.social> hello

<r​brunner7:monero.social> SNeedlewoods: You mean with the CLI wallet running on Wallet API?

<s​needlewoods_xmr:matrix.org> exactly

<r​brunner7:monero.social> Nice milestone :)

<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 ...

<s​needlewoods_xmr:matrix.org> picked almost all the low hanging fruits and now more complex stuff is still left

<h​into:monero.social> me: thinking about how to implement PoWER with as few diffs as necessary

<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

<r​brunner7:monero.social> hinto: Cuprate, yes?

<j​berman:monero.social> me: announced FCMP++ & Carrot alpha stressnet v1 (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

<h​into:monero.social> for both `monerod` and `cuprated`

<r​brunner7:monero.social> Somebody should put up a nice countdown to October 3, with carrots or so

<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 :)

<r​brunner7:monero.social> So first stressnet will still run without PoWER, obviously

<j​berman:monero.social> Yep

<r​brunner7:monero.social> Maybe a good chance to see what happens without that as protection

<k​ayabanerve:matrix.org> Hello, y'all! Congrats to everyone on the tagged network release!

<h​into:monero.social> jberman: is there any notable behavior or logs to look for when running the 0.19 binary?

<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

<h​into:monero.social> also would the official `monerod` release be an opportunity for `v1.0.0`?: monero-project/meta #721

<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.

<r​brunner7:monero.social> hinto: That's almost a heresy

<k​ayabanerve:matrix.org> (solely their constants)

<r​brunner7:monero.social> No big deal, implementation-wise, right?

<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.

<r​brunner7:monero.social> Helios/Selene, now even more curvy

<k​ayabanerve:matrix.org> It will be a hard fork though 😱😱😱😱 So stressnet will use the old curves until a new net is created.

hey

<r​brunner7:monero.social> And of course no speed difference, the code being constant-time

<k​ayabanerve:matrix.org> And because the new parameters won't involve changing any of our methodology

<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.

<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

<r​brunner7:monero.social> Is that within the CCS framework, or a different "account" to pay for your Serai work?

<j​berman:monero.social> different account, completely separate from CCS

<r​brunner7:monero.social> Ok, good so now misunderstandings and complaints will crop up

<r​brunner7:monero.social> Some people on Reddit are trigger-happy with such stuff :)

<r​brunner7:monero.social> (Not that this means much)

<r​brunner7:monero.social> Alright, looks like we are through with the reports. Anything else to discuss today?

<r​brunner7:monero.social> Does not look like it. So thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> Question about fee priority:

<s​needlewoods_xmr:matrix.org> (First a little shout-out: thanks to [this PR](monero-project/monero #9838) the fee priority code in wallet2 is less confusing now.)

<s​needlewoods_xmr:matrix.org> Below is some common terminology that's used for the 4 different levels + a default value

<s​needlewoods_xmr:matrix.org> 0 Default

<s​needlewoods_xmr:matrix.org> 1 Unimportant / Low

<s​needlewoods_xmr:matrix.org> 2 Normal / Medium

<s​needlewoods_xmr:matrix.org> 3 Elevated / High

<s​needlewoods_xmr:matrix.org> 4 Priority / Very High

<s​yntheticbird:monero.social> JIT

<s​needlewoods_xmr:matrix.org> Unfortunately the Wallet API uses a differnt term for the fifth element in the enum: `Priority_Last` ([src](github.com/monero-project/monero/bl…rc/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](gi<clipped

<s​needlewoods_xmr:matrix.org> thub.com/monero-project/monero-gui/blob/440012b454a39de860c97226e33af204ced868ec/src/libwalletqt/PendingTransaction.h#L62-L66))

<s​needlewoods_xmr:matrix.org> So my question, should I

<s​needlewoods_xmr:matrix.org> a) rename `Priority_Last` to `Priority_VeryHigh`?

<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`.

<s​needlewoods_xmr:matrix.org> c) do nothing?

<r​brunner7:monero.social> Will try to have a look to build an informed opinion

<s​needlewoods_xmr:matrix.org> alright thanks, nothing else to discuss for me