<r​brunner7:monero.social> Meeting in 1 hour. Now also Europeans can enjoy the great civilizational achievement of daylight saving time.

<i​ntr:unredacted.org> truly one of the great pillars

<s​yntheticbird:monero.social> f*ck daylight saving. everything should be UTC and people should get used to have morning a 10pm

<r​avfx:xmr.mx> Imajing still having DST, in 2026!!!

<r​brunner7:monero.social> SyntheticBird: That's the spirit. I am jet-lagged a bit from getting up 1 hour too early in regard to my inner clock

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

<s​needlewoods_xmr:matrix.org> Hi

<j​pk68:matrix.org> Hello

<s​yntheticbird:monero.social> Hi

<v​tnerd:monero.social> Hi

Hi

<j​effro256:monero.social> Howdy

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

<j​babb:cypherstack.com> doing well thanks, howdydo?

<r​brunner7:monero.social> Alrigh, plenty of people today, nice. What are your reports from last week?

<s​needlewoods_xmr:matrix.org> `grep "\<m_wallet\>" src/wallet/wallet_rpc_server.cpp -c` returns 0

<s​needlewoods_xmr:matrix.org> Now focus is on functional_tests, find and fix bugs not covered by tests, clean up code and notes

<s​needlewoods_xmr:matrix.org> Also just posted a final report on my [current CCS proposal](repo.getmonero.org/monero-project/c…als/-/merge_requests/634#note_35515) and began to write a [new CCS proposal](paste.debian.net/hidden/561205b1)

<r​brunner7:monero.social> I myself wanted to continue to work on Polyseed, but did not find the necessary free time ...

Reviewing carrot_core. Pointed out some limitations of the PQ turnstile design to jeffro256.

<j​berman:monero.social> me: completed the monerod hang-on-exit PR and submitted it ( monero-project/monero #10382 ), various FCMP++ integration cleanup / upstream monerod cleanup tasks

Next, will write an issue advocating for more jamtis features now instead of later. Won’t do any other work on it without strong buyin.

<r​brunner7:monero.social> Not sure I understand. You mean if your proposals don't find strong support you are ready to move on from Carrot into other topics?

Yes, either review carrot_impl or start on multisig.

<j​effro256:monero.social> Me: talking to Koe about CARROT/Jamtis, talking to vtnerd about LWS, reviewing H1 issues, talking to auditors about the FCMP++ integration, talking to Ledger about HW development, rebased the knowledge proofs PR and working on completing the remaining tasks

<s​yntheticbird:monero.social> do you happen to take your breath in between ?

<r​brunner7:monero.social> Just curious anyway, what is an example for one of the Jamtis features that you would want Carrot to learn, UkoeHB?

rbrunner7: encoded address index + filter-assist key

<j​pk68:matrix.org> Any success with contacting Trezor?

<r​brunner7:monero.social> Ah, ok. I remember quite vidid discussions about Seraphis indexes, probably without ever reaching a clear consensus :)

<j​pk68:matrix.org> I can't remember if you said you emailed the dev or the company :)

<j​berman:monero.social> btw sgp_ is about to do an audit blitz reaching out to some more candidates soon, would be good to coordinate comms

Mostly complaints about adding bytes.

<j​effro256:monero.social> I emailed the company a few months ago, but they never really followed up until someone else who had personal connections poked them about it recently, very grateful

It sounds like mx25519 has not been touched by any audit. jberman/jeffro256 can you work it into the audit cycle?

<j​effro256:monero.social> ^ My previous comment is about Ledger. Trezor said that they would forward it to a product manager and never got back

<j​berman:monero.social> I liked the address indexes and filter-assist key. I'm open to re-opening a discussion on them, with strong emphasis on still ensuring FCMP++ launches within a timely manner

<r​brunner7:monero.social> I wonder what their lead development times would be to be fully ready with a new FCMP++ capable firmware when we hardfork.

<j​effro256:monero.social> I think mx25519 would be a good candidate for the optional follow-up PR which covers the more complex wallet-specific crypto like the point checking by fast halving

<j​berman:monero.social> mx25519 seems like a good candidate to be reviewed in an isolated audit by auditors proficient in C & crypto

<j​effro256:monero.social> At the least, basically anyone can verify that `mx25519` hits the standard test vectors for X25519 and doesn't use branching in the assembly

<j​effro256:monero.social> Fair

<j​effro256:monero.social> They need to be proficient in assembly though mainly

<j​berman:monero.social> true, yes

Are the text vectors considered adequate for validity?

<j​berman:monero.social> seems a marginally distinct skillset enough to warrant a distinct audit

<j​berman:monero.social> edit out the marginally*

<r​brunner7:monero.social> Could that mean another Carrot "crypto" review if we change anything non-trivial like indexes and/or another key like that?

<j​effro256:monero.social> There's an x64 impl, an x64 with mulc/adc extensions impl, an ARM64 impl, and a portable C impl.

<j​effro256:monero.social> UkoeHB: IDK, so I would leans towards "no"

rbrunner7: likely yes

<j​effro256:monero.social> But it's a baseline test for completeness

<r​brunner7:monero.social> I see. But could heavily build on what already happened there review-wise, I guess

<j​effro256:monero.social> Yes

If there’s buy-in, I will write a PR on carrot_core with the changes so the full scale can be more accurately seen. But let’s wait until the points in favor are laid out.

<j​effro256:monero.social> Ukoe makes really good arguments for basically shifting the new key hierarchy into Jamtis, but I am personally against it for the moment, especially if we go for hard separation in issue seraphis-migration/monero #306. Perhaps I could write up an issue showing pros and cons of both

<r​brunner7:monero.social> Just wanted to ask whether anybody see a benefit if we discuss h306 here today, or do we just let that collect comments and votes for some time more :)

Not sure how many other contributors have not commented

<r​brunner7:monero.social> I think jberman is the most prominent there

<j​berman:monero.social> I meant to write up a comment, but I'm still pretty strongly in the camp of hard separation. I think tevador's arguments strenghthend the argument for separation and I was already for separating

<j​berman:monero.social> (as did rbrunner's)

<r​brunner7:monero.social> So maybe a short comment from you will already do, do make your mark clearly in a place that is visible also to people who don't follow meetings and discussions here

<j​berman:monero.social> I will

<j​berman:monero.social> jeffro256: I'm curious if you have some cons top-of-mind rn on bringing in the address index + filter-assist key

<r​brunner7:monero.social> The new comments from jeffro convinced me that on the side of the the implementation on the side of core wallet code the hybrid scheme can work, and we would probably able to pull it through, but that does almost nothing to diminish my fears of potential chaos in the wallet apps

sneedlewoods_xmr also

<r​brunner7:monero.social> Right, I think so far there is only a "like" from them somewhere, but no comment

<r​brunner7:monero.social> Ok, looks like we just come back to this next week, and then we can maybe chat about how to reach something like a "loose consensus" on this

<s​needlewoods_xmr:matrix.org> yes, I +1'ed rbrunner, not sure if I have anything worth to add

<r​brunner7:monero.social> Cannot fail to remark that heavy "pro" votes are somewhat lacking ...

<j​effro256:monero.social> Cons against adding address index + filter assist key is mainly two things. One, the added complexity to the addressing protocol which is already complicated. And two, the privacy implications of having people be on two completely separate distinguishable address formats. Most users probably won't be using the filter-assist tier, and would get the main benefits of the new key hier<clipped

<j​effro256:monero.social> archy without needing a change in address format. Also, the main benefit of address indexes I think is lost if one changes the way that they scan, in such a way that they can save all txs which may potentionally belong to them. Think of background scanning, but even more selective.

<r​brunner7:monero.social> There would be a need of change of address format?

<r​brunner7:monero.social> Like in "public Monero addresses"

<j​berman:monero.social> ahhh right new filter-assist tier requires a new key pair ya?

<j​berman:monero.social> so addresses would be longer too

<j​effro256:monero.social> Yes, adding address indicies + filter-assist requires a new 8 byte field and 32-byte elliptic curve point in the address, respectively

<j​berman:monero.social> So there's no way of incorporating the new address index without making the new address indistinguishable from old either

<j​effro256:monero.social> Not that I know of

<r​brunner7:monero.social> Hmmm ... that seems to go against one of the core achievements of Carrot, at least as I see them, that addresses magically don't have to change to still get solid benefits

The PQ scheme will do that anyway, it’s inevitable with current plans. Now is better than later for racing against adversaries.

<r​brunner7:monero.social> Yes. But might be some years out, I guess?

Ok my argument is weak * in any case, GitHub is better for laying out the case.

<j​berman:monero.social> I figured even Carrot addresses won't work in a fully PQ scheme

<r​brunner7:monero.social> Yes, that proposal of Tevador which seems quite concrete already has longer addresses, do I remember correctly?

<j​effro256:monero.social> What do you mean by "fully" PQ?

<r​brunner7:monero.social> I think there is it: monero-project/research-lab #151

<j​berman:monero.social> A scheme that includes PQ key exchange

<j​berman:monero.social> (but is not limited to)

Yes, the change would be moving new features from PQ scheme to now, and then PQ would just add PQ. So there’d be two address changes instead of one, but the features would be now instead of later (or never).

<r​brunner7:monero.social> Could develop into interesting trade-offs then :)

<r​brunner7:monero.social> Let's see whether our decision processes will be able to cope with those ...

<j​effro256:monero.social> As for the address distinguishability problem, there is an argument is Koe's favor towards "ripping the bandaid off" now if we plan to support Jamtis later. Since if the new key hierarchy already exists and is used, then Jamtis is implemented, the only people who would really need to move to Jamtis would be the filter-assist light wallet users. Then one can categorize a Jamtis use<clipped

<j​effro256:monero.social> r as *probably* a filter-assist user

Filter assist or using random address generation (assuming 16 byte indices). Or enterprise with advance index usage.

rag might be favored by the most privacy conscious.

<j​effro256:monero.social> Yup

Which really covers the two biggest camps: mobile and privacy focused

<j​berman:monero.social> Personally I think the con of new distinguishable address is a legitimate con that does weigh in to my calculation here pretty solidly (especially when weighed together with keeping a sane timeline for FCMP++)

<j​berman:monero.social> I do think there will be support to incorporate it once we have no choice to migrate to a new distinguishable address type

<j​berman:monero.social> These features were relatively popular when it was discussed / proposed for Seraphis + Jamtis

<r​brunner7:monero.social> I am quite unsure here. I just looked up the English translation of a famous German saying and found "a bird in the hand is worth two in the bush". That what comes to my mind right now with all those wonderful things that we could implement, but maybe should not, to protect a sane timeline

<s​yntheticbird:monero.social> this

<s​yntheticbird:monero.social> I just don't have technical arguments but gosh its how i felt

<r​brunner7:monero.social> Alright, I hope people will find time soon to lay out things clearly in some GitHub issues, so people can look at that and "meditate" over it

<j​berman:monero.social> I also do strongly favor advancing PQ research after FCMP++/Carrot

<j​berman:monero.social> so it's not like a hand wavy thing

<j​berman:monero.social> I think that's a critical direction

<r​brunner7:monero.social> So that could maybe start earlier if we finish early with the hardfork to FCMP++ :)

<r​brunner7:monero.social> Alright, let's see how proposals and opinions here develop further over the coming week.

<r​brunner7:monero.social> Anything left for this very meeting?

<s​needlewoods_xmr:matrix.org> not for this meeting, but would appreciate some feedback on this PR monero-project/monero #10378

<s​needlewoods_xmr:matrix.org> what are your opinions on:

<s​needlewoods_xmr:matrix.org> a) Should `get_tx_proof`, `get_spend_proof` & `get_reserve_proof` get restricted? I didn't see a good reason to do so.

<s​needlewoods_xmr:matrix.org> b) Should `relay_tx` get restricted? I'm leaning towards no, because even though it's a "state-changing" command, you can't really do anything with it without getting the raw tx from an unrestricted wallet-rpc (or some other unrestricted wallet) first, AFAICT.

<s​needlewoods_xmr:matrix.org> c) In [10271](monero-project/monero #10271) it was argued that there is no privacy loss in allowing `get_transfers` & `get_transfer_by_txid`, because `get_tx_key` is unrestricted anyways. I did restrict it in my PR, do you think it should stay unrestricted?

<r​brunner7:monero.social> Alright, will try to find time to have a look

<r​brunner7:monero.social> So it looks like we can close for today. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> Thanks everyone, good meeting, cu

Thanks

<o​frnxmr:monero.social> i would argue that get_tx_key and get_*_proof don't need to be restricted