<dennis_tra:matrix.org> Hi folks, a few days ago we've opened this CCS funding proposal: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 we would love to get more feedback! It's basically about adding continuous monitoring of P2P layer metrics and displaying them publicly as well as a more research-heave milestone about identifying unreachable nodes.

@jeffro256 in Jamtis-RCT, d_e was derived as: KeyDerive1("jamtis_legacy_sending_key" || anchor || a || K1 || K2 || pid)

In Carrot you changed it to: d_e = ScalarDerive("Carrot sending key normal" || anchor || input_context || K1 || pid)

Why did you remove K2? It has some privacy implications for Jamtis.

tevador: what privacy implications?

<quadriocellata:matrix.org> @articmine:monero.social or others : I remember reading/listening some time ago about Monero scaling, that it has a problem right now (growth rate could be too large should we see rapid adoption according to bandwidth and/or storage limits). Therefore for the hardfork this will be addressed by reducing the scaling rate and ens [... too long, see mrelay.p2pool.observer/e/u7XCtvkKeVhXR0Rr ]

It's a relatively minor thing, but still annoying. The Carrot PQ turnstile spend publishes enough secrets for any observer to derive d_e and check if the spent enote is a Carrot or Jamtis enote. If K2 was in the derivation, this would not be possible.

<jeffro256> tevador: mainly it was removed to simplify the scanning code

<jeffro256> That's an interesting side effect I hadn't considered... That might be worth putting K^j_v back in

<jeffro256> For external enotes, one already needs to have their k_v on hand in case of a special enote Janus check

<jeffro256> So actually, it might not be much more complicated to put K^j_v back in

<rucknium> @dennis_tra:matrix.org: Thank you. I will put repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 on the MRL agenda, tomorrow at 17:00 UTC. Feel free to join.

<rucknium> It might have a small amount of time because the agenda will be packed. It will probably be discussed next week too.

<ofrnxmr:xmr.mx> @rucknium: ty. I was about to ask you

<ofrnxmr:xmr.mx> (Grease, ProbeLab, fcmp++ integration audit)