<onyx_prot:matrix.org> To clarify the scope:

<onyx_prot:matrix.org> monero-serai assumes persistent wallet state for key image and commitment

<onyx_prot:matrix.org> mask derivation. That works for nodes/servers, but not for browsers.

<onyx_prot:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/--z53OIKNWphZHBY ]

<kayabanerve:matrix.org> @onyx_prot:matrix.org: I'm unsure what you mean about assuming 'persistent wallet state'. Key images also cannot be derived from view keys only, and shares of a view key _inside the hash function_ wouldn't be homomorphic. It increasingly sounds like you're deferring to an LLM which is misleading you.

<kayabanerve:matrix.org> If you want to share your work though, please do so.

<onyx_prot:matrix.org> @kayabanerve:matrix.org: You're right, I compressed too much. Let me clarify:

<onyx_prot:matrix.org> Key images: KI = x * Hp(P) — uses spend_key shares, FROST aggregates

<onyx_prot:matrix.org> partial KIs. Server holds 1 share, threshold is 2, can't compute alone.

<onyx_prot:matrix.org> Commitment masks: view_key ECDH, computed client-side:[... more lines follow, see mrelay.p2pool.observer/e/v9TN7OIKWGI1d2Rp ]

<kayabanerve:matrix.org> 1) That even more sounds like an LLM output.

<kayabanerve:matrix.org> 2) monero-oxide doesn't use `.keys`.

<kayabanerve:matrix.org> So not to say your work doesn't contribute, to say if your reasoning against monero-oxide is the usage of `.keys`, you're misinformed on that topic.

<kayabanerve:matrix.org> Though again, if you have a contribution, please, share it. Solely talking about as an idea obviously causes a lack of proper context

<onyx_prot:matrix.org> Fair. Here's actual code, not LLM summary:

<onyx_prot:matrix.org> 1. Lagrange coefficients for 2-of-3 (frost_dkg.rs):

<onyx_prot:matrix.org> pub fn compute_lagrange_coefficients(signer1: FrostRole, signer2: FrostRole) -> (String, String) {[... more lines follow, see mrelay.p2pool.observer/e/s-Tm7OIKYVc1aV9U ]

<tobtoht> Ban?

<kayabanerve:matrix.org> monero-oxide's monero-wallet does not require any daemon.

<kayabanerve:matrix.org> Not to say it meets your needs, to clarify that comparison still seems inaccurate.

<kayabanerve:matrix.org> None of those code snippets are remarkable, being a straightforward lagrange interpolation and simple commitment mask derivation. I'd recommend linking a GH repo, or yes, not bothering to continue talking about the code you won't actually publish for discussion here.

<kayabanerve:matrix.org> Though I wouldn't outright call for a ban 😅

<kayabanerve:matrix.org> But in general, since this seems like an LLM, I'd say yes, it's probably a waste of time.

<onyx_prot:matrix.org> hhhh You're right. Crypto is standard, nothing new there.

<onyx_prot:matrix.org> The work is a shipped escrow product — browser UI, API, dispute

<onyx_prot:matrix.org> resolution. That's it.

<onyx_prot:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/jqz87OIKSURfSnA3 ]

<hooftly:matrix.org> bro

<kayabanerve:matrix.org> K, now I'm call for ban lol

<kayabanerve:matrix.org> @tobtoht:monero.social: was right

<ofrnxmr> Fkn skull / facepalm

<ofrnxmr> Even the linebreaks are pasted from the bot

<plowsof:matrix.org> banned

<syntheticbird> YES YES YES YES YES.*

<syntheticbird> I LOVE THE HAMMER

<rucknium> @kayabanerve:matrix.org: Can you attend the MRL meeting tomorrow? Two agenda items relevant for you: zkSecurity quote for reviewing Elliptic Curve Divisors for FCMP++ and Goodell (2026) "Generalized Bulletproofs for Opening Vector Commitments." (github.com/cypherstack/generalized-bulletproofs-fix)