<k​ayabanerve:monero.social> In general, we should probably keep CCS discussions to -community.

<r​brunner7:monero.social> > seraphis is out of reach for the next few years

<r​brunner7:monero.social> It's astonishing how this claim propagates

<r​brunner7:monero.social> As if there may be people around who *want* to have that 3, 4, 5 years out ...

<r​brunner7:monero.social> > gas lighting for FCMP

<r​brunner7:monero.social> I don't exactly what that means, but I counter with "The gras is always greener over there" :)

<r​brunner7:monero.social> I see myself out, this is the MRL room ...

<k​ayabanerve:monero.social> rbrunner7: jberman was 3y I believe, if with FCMPs. The most favorable version I've seen is ~1.5y. I'm unsure I've heard your explicit estimate, but between that and koe's own estimate... I at least understand why the claim is being propagated.

<k​ayabanerve:monero.social> Though I don't think anyone is gas lighting re: FCMPs 😅

<binaryFate> Hey all, as you know we usually cover ~1/3rd of "fundational" (whether dev or research) CCS proposals, from the General Fund.

I don't see a reason to use General Fund at this point, as we can simply fund proposals trough CCS and keep rainy fund for the rain

(hopefully never)

another remark, skipping community to vote for proposals in MRL is kind of wrong, there is technical and business aspects of the community / problem

we can't expect devs working on coding or math problems to be fully into the wider community aspects with all due respect, its kind of frustrating sometimes to be into loop for all of the happening

so we can't blame them later for making decisions which lead to milky or community money waste

<MajesticBank> I don't see a reason to use General Fund at this point, as we can simply fund proposals trough CCS and keep rainy fund for the rain <-- doing so has long been a public policy of the GF, so I intend to honor that practice for all donors' sake

<u​ntraceable:monero.social> If general fund ceases to fund ccs proposals what incentive would there be for these whales to keep making large donations like we have seen in the recent weeks? Donor would see that the money is not put to use and stop donating. What is a "rainy day" anyway? But I digress

I read through gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86, which is kayabanerve's proposal for replacing CLSAG with a FCMP. The membership proof design is at least plausible on the surface (it follows a similar pattern to what we're doing in Seraphis and Lelantus Spark), although I don't know if it can actually be implemented securely with these 'generalized bulletproofs'. The proposed timeline

of 1 year to deployment is very optimistic, I'd put it more like 2 years based on the current pace of Monero development and review. Writing proofs is much faster than all the other tasks to bring a new (very complicated and advanced) proof structure onto mainnet. I'm also skeptical about bringing in a Rust dependency, which would be a major shift in the Monero core repo (not to mention bloating binary sizes).

I'll add this comment to the CCS as well.

<r​ucknium:monero.social> Thank you, koe

Short update on my current CCS: I scraped together 38.25hr since June of last year (mostly on PR reviews, with the bulk aimed at jeffro's Jamtis updates), and have 117hr remaining.

<s​yntheticbird:monero.social> > I'm also skeptical about bringing in a Rust dependency, which would be a major shift in the Monero core repo (not to mention bloating binary sizes).

<s​yntheticbird:monero.social> The ideal solution, regarding binary size, would be for kayaba's library to be `no_std`, it is theorically possible since `crypto-bigint` (and generally RustCrypto) has been written with `no_std` in mind. Tho, I'm not sure kayabanerve genuinely wish to spend time in this realm.

<s​yntheticbird:monero.social> > I'm also skeptical about bringing in a Rust dependency, which would be a major shift in the Monero core repo (not to mention bloating binary sizes).

<s​yntheticbird:monero.social> The ideal solution, regarding binary size, would be for kayaba's library to be `no_std`, it is theorically possible since `crypto-bigint` (and generally RustCrypto) has been written with `no_std` in mind. Tho, I'm not sure kayabanerve

<s​yntheticbird:monero.social> genuinely wish to spend time in this realm.

<k​ayabanerve:monero.social> no_std can cause usage of less efficient or less secure solutions and should not be used here.

<k​ayabanerve:monero.social> And no, we can't use no_std unless we take a rand seed on init and use a seeded CSRNG for all entropy.

<s​yntheticbird:monero.social> Interesting, I didn't know this could cause these difference. I also haven't think about the CSRNG.

<k​ayabanerve:monero.social> Take HashMap. std seeds from RNG to prevent certain DoSs. no_std frequently causes a fallback to hashbrown which doesn't.

<k​ayabanerve:monero.social> Also, some libs alias no_std to low memory variants of algorithms (increasing runtime).

<w​ayfndr:envs.net> @kayabanerve if I may take the position of devil's advocate, the code can be written to support no_std without requiring users to use it. Using std could still be the default feature configuration, and for those that want no_std, passing in a random seed at runtime is a relatively easy problem to solve

<w​ayfndr:envs.net> A huge benefit to no_std compatibility that is often overlooked, is embedded hardware compatibility. It becomes possible to run on microcontrollers (e.g. hardware wallets) or obscure CPU architectures that don't have std support. Making std software support these targets is a much more difficult task than designing good no_std software

<s​yntheticbird:monero.social> Huh. Have anyone thinked about monerod targets ??? I'm for including rust in monerod as I'm part of the Rust evangelist strike force, but iirc monerod support targets that are unsupported by Rust std.

<s​yntheticbird:monero.social> `x86_64-unknown-freebsd`, `x86_64-unknown-netbsd` are Tier 2 with Host Tools

<s​yntheticbird:monero.social> `aarch64-unknown-freebsd`, `aarch64-unknown-netbsd`, `aarch64-unknown-openbsd`, `riscv64gc-unknown-openbsd`, `x86_64-unknown-openbsd` are Tier 3