<r​ucknium:monero.social> MRL meeting in this room in one hour.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1092

<r​ucknium:monero.social> 1) Greetings

<t​obtoht:monero.social> hi

<c​haser:monero.social> hello

<b​oog900:monero.social> Hi

<v​tnerd:monero.social> Hi

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

<j​effro256:monero.social> howdy

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<k​ayabanerve:monero.social> 👋

<k​ayabanerve:monero.social> FCMP++ stuff for jberman.

<j​berman:monero.social> wallet sync for fcmp++

<j​effro256:monero.social> Carrot shtuff

<v​tnerd:monero.social> Fixed LWS bug, working on more http async stuff for lws, and a bit of work on span code in daemon

<r​ucknium:monero.social> Posted summary for Milestone 1 of my statistical research CCS: repo.getmonero.org/monero-project/c…als/-/merge_requests/439#note_26679 . Now working on OSPEAD.

Hello. A bit late, but here

<0​xfffc:monero.social> Hi everyone.

<r​ucknium:monero.social> rbrunner: Was it because I posted only one hour notice for the meeting instead of two? :P

:) No, mea culpa

<r​ucknium:monero.social> 3) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. getmonero.org/2024/04/27/fcmps.html github.com/jeffro256/carrot/blob/master/carrot.md

<r​ottenwheel:kernal.eu> OSPEAD... Cue meme gif... It's been 84 years.

<j​effro256:monero.social> The CCS for Carrot review got merged, congrats Cypherstack!

<r​ottenwheel:kernal.eu> Hopefully getting some news on that front soon! We know you've been busy with other stuff, not pissing on it. Just saying it has been long since we last got anything on it. 👍

<r​ottenwheel:kernal.eu> 🚀👍

<0​xfffc:monero.social> Finished dynamic-span and dynamic-bss, going through review. Will push few minor updates I have this week ( rpc limit fix, and a PR related to public-node flag )

<r​ucknium:monero.social> Here is the Carrot review CCS for reference: ccs.getmonero.org/proposals/cypherstack-carrot-spec-review.html

<j​effro256:monero.social> Throwing the idea out there to have the GF help fund the review. Good idea or bad idea?

<r​ucknium:monero.social> Do we want to talk about the custom lock time outputs and FCMP?

<j​effro256:monero.social> Yes

<j​berman:monero.social> yes

<r​ucknium:monero.social> Discussion begins here: monero-project/research-lab #78#issuecomment-2415324570

<j​effro256:monero.social> I'll publish that script to determine the running size of the wallet locked output cache today btw, I fell asleep coding it last night haha

<j​berman:monero.social> Feeling a pretty solid "rough consensus" on removing custom timelocks

<r​ucknium:monero.social> `git blame` really earns its name with this "feature".

<j​berman:monero.social> I figure that comment should be enough to move it over the goal line for the fcmp++ fork: to remove a dos vector / vector to slow down scanning under fcmp++

<j​effro256:monero.social> I'm in favor of making a public announcement to stop honoring custom timelocks after height X in the FCMP hard fork, and not actually soft forking now

<k​ayabanerve:matrix.org> I support removing timelocks entirely at the fork due to concerns re: wallets.

Which variant is currently favored - not honoring *any* timelocks, starting at genesis block, or only honoring them up to a fixed height X?

<k​ayabanerve:matrix.org> NACK, I'm not in favor of invalidation at this time.

<r​ucknium:monero.social> I also support removing the ability to create new custom time locks at the next hard fork.

<j​berman:monero.social> ya can you clarify the approach there @jeffro256 ? do you mean that a tx currently in the chain with timlock set to unlock past X is now unlocked at X?

<j​effro256:monero.social> Let me be clear: not invalidating currently on-chain timelocks, just ignoring non-zero unlock times for *future* outputs that have yet to be created when building the FCMP tree

Yeah, I think that pretty much consensus. I would not feel too good however stopping to honor any existing locks at all.

<j​berman:monero.social> makes more sense, I misunderstood

Oh, there are two questions. Whether allowing new timelocks, or not, starting at a given height. And, not honoring locks anymore that would only expire past some horizon, block X.

<k​ayabanerve:matrix.org> Tbf, I'm in favor of timelock invalidation when we do a PQ migration.

<j​berman:monero.social> one quasi-issue with the approach to consider is that a miner (or someone who can get their txs to a miner running a daemon wtihout the relay rule) can spam timelocks up until the fork, which would still affect wallet scanning

<j​effro256:monero.social> So for example, in your unlock_time -> unlock_block_index function, adding an `if` branch that says if the output creation block index is greater than 3300000 (a height which doesn't exist yet as of the time of this writing), then always use the default unlock block index

<j​berman:monero.social> soft fork gives us the full knowledge of how many timelocks there will be at time of fcmp fork

<k​ayabanerve:matrix.org> Because of that, it doesn't really hurt to get it over with now for the 0.001% affected.

<j​effro256:monero.social> Yes miner's can still spam locked outputs

<k​ayabanerve:matrix.org> I wouldn't ignore. I'd require 0

I am not sure I understand what you mean with "soft fork"

<j​effro256:monero.social> Ignoring after height X would also let you know how many locked outputs before the actual deployment of the code

<j​effro256:monero.social> rbrunner: restricting the content of transactions to things already allowed is a soft fork, not a hard fork

<j​berman:monero.social> a soft fork that stops allowing future timelocked txs to be created at height X, before the fcmp fork

<k​ayabanerve:matrix.org> It seems like we all agree on requiring timelock 0 at the fork. The question then becomes relay rules/soft forks/invalidation. I support relay rules over a soft fork.

<j​berman:monero.social> we already have relay rules in place

Yes. It's already pretty difficult to put custom locks.

<j​berman:monero.social> "Ignoring after height X would also let you know how many locked outputs before the actual deployment of the code" -> I don't follow this. The code would be deployed before the fork height

<j​effro256:monero.social> I will say though, that during the fork to enforce zero unlock times, we could also integrate tevador's intermediate hash changes. This would turn it into a hard fork, but gives us extra time to mitigate problems that arise with the intermediate hash if they exist before the FCMP hard fork

<k​ayabanerve:matrix.org> Are the relay rules for all timelocks or just time-based timelocks?

<k​ayabanerve:matrix.org> I thought solely the latter

<j​effro256:monero.social> For example, we could announce the ignore height to be 3300000 beforehand. Then, after height 3300000 we do analysis of existing time locked outputs. Then we plan FCMP hard fork for 3500000 and deploy sometime around block 3400000. So in order: announcement, ignore height hits, analysis, code deployment, hard fork activation

<j​effro256:monero.social> All time locks

<j​berman:monero.social> ah I see, that makes sense

<j​effro256:monero.social> Coinbase transactions require non-zero unlock times, but the relay rule won't touch them

<j​berman:monero.social> +1 to that approach from me

Unfortunately I am still not fully sure what people mean with "ignore height". Say, 2 years ago a made a transaction to unlock at block 5,000,000. When will it be free, according to proposals?

At an earlier "ignore height", or at 5,000,000 in any case?

<j​berman:monero.social> With that approach: it's unaffected, still 5,000,000. Only *new* outputs created past the ignore height would be affected

<r​ucknium:monero.social> So the proposed threat model is that there is an adversary that would spam locked outputs between now and the FCMP hard fork, yet would not spam locked outputs between the announcement and "height 3300000".

<k​ayabanerve:matrix.org> Ah. Ignore w.r.t. accumulation. ACK.

<j​effro256:monero.social> Any output *created* before the ignore height would have its unlock time respected in perpetuity. Any output *created* after that height is not guaranteed to have it's unlock time respected

<j​berman:monero.social> fwiw even if they were to spam, it wouldn't be the end of the world. it would just take more analysis to be sure it's still ok

<r​ucknium:monero.social> By "spam txs" I mean create the txs and somehow get around the relay rules to get the txs confirmed in mined blocks.

I see, thanks. I would be in favor of a blockheight pretty soon that stops to honor new locks, eventually. If we just keep "social contracts" in force earlier.

So there is not much to spam.

<j​berman:monero.social> so to answer your question @Rucknium yes, but this approach can yield 100% confidence wallets will sync smooth given whatever an adversary does

<c​haser:monero.social> is anyone monitoring the growth of time-locked outputs? do we have an idea how sensitive this seems to be currently?

I mean, we could announce such a height today, right? Technically, no need to wait until the software is ready?

<j​effro256:monero.social> I will released a script today to have the exact number at each step of the sync

<j​berman:monero.social> in the worst case, wallets have to download 2x data for timelocked outputs

<j​effro256:monero.social> rbunner: yup, exactly

<j​berman:monero.social> 72 bytes extra per timelocked output*

I finally got it :)

<c​haser:monero.social> given what we were showered this year, I agree with rbrunner, the sooner more obstacles are deployed, the better

<c​haser:monero.social> *showered with

<j​berman:monero.social> thank you @jeffro256

<c​haser:monero.social> great, thank you!

It's a bit unsual regarding forking customs, however, such an announcement ...

<r​ucknium:monero.social> Well, isn't there a concern about centralisation of development? This topic wasn't even explicitly on today's agenda. And was just brought up less than 24 hours ago.

<j​berman:monero.social> we're here doing the discussion now. can let the idea of this proposed announcement marinate longer for its "rough consensus"

<k​ayabanerve:matrix.org> Not when it's a DoS causing the harsher crackdown of an already planned and agreed to crackdown (we have a relay rule).

<c​haser:monero.social> Rucknium I don't see an issue with that. new ideas enter these conversations organically.

<k​ayabanerve:matrix.org> I'm not saying it needs action overnight, I'm saying timelocks are at their end.

I think such an announcement does not make "centralization" worse. Even if we pre-announce all kinds of things about our next release, people are free to ignore it, as they ever were.

<j​effro256:monero.social> I don't plan to decide the height today, but the announcement only *means* anything when the FCMP code is introduced. It's basically just a nicety to manage expectations for the future hard fork. If people don't merge the FCMP code into their daemons in the future, then the announcement means nothing to them. In other words, I think it has the same centralization implications as n<clipped messag

<j​effro256:monero.social> ormal Monero hard forks

<k​ayabanerve:matrix.org> If we tweak how they're at their end, I don't think we need months of work.

<j​berman:monero.social> there's also years of "rough consensus" building to remove timelocks, this is the discussion on "how"

<k​ayabanerve:matrix.org> Besides, deciding an ignore date isn't final. It's still a pending decision till the time of fork.

Wouldn't rule out that tomorrow it starts raining timelocked txs, just to mock us :)

<j​effro256:monero.social> That'd suck ;) But IMO announcing a soft fork to remove unlock times for the exact same reason could just as easily trigger a malicious actor to precipitate that action up until the point of the fork

<k​ayabanerve:matrix.org> IRC in TX extra D:

<k​ayabanerve:matrix.org> We could say all timelocks from after this meeting will be ignored.

<r​ucknium:monero.social> "Besides, deciding an ignore date isn't final. It's still a pending decision till the time of fork." This statement does not remove the centralisation of development concern. Makes it worse. At any time a small group of devs could decide what outputs are spendable and unspendable.

<c​haser:monero.social> jeffro256 exactly.

"At any time a small group of devs could decide what outputs are spendable and unspendable" Well, it ever was like that, no? At least as a possibility.

<0​xfffc:monero.social> I don’t have enough information to discuss technical intricacies of such decisions. But wouldn’t it be better, if we decide to do it, do it in hardfork?

<j​berman:monero.social> no one has made any decision yet? we are signalling support for a technical idea that makes sense for people to consider?

It always was a pretty small group of devs bringing out releases, after all.

<k​ayabanerve:matrix.org> May I posit it this way?

<k​ayabanerve:matrix.org> We already have consensus on ending time locks.

<k​ayabanerve:matrix.org> Due to a DoS, it makes sense to potentially ignore some timelocks, anywhere from none to all timelocks after this meeting.

<k​ayabanerve:matrix.org> We will decide at the hard fork which will have the expected community consensus process.

<k​ayabanerve:matrix.org> The question is how do we want to make the community aware of this discussion and can we provide a firm estimate for which block we'll ignore timelocks from?

<k​ayabanerve:matrix.org> Instead of the handwavy discussion of 'may or may not be invalidated at any point after this'

<r​ucknium:monero.social> I'm not really against it. I'm just saying it has some centralisation downsides that should be brought up. Everything is a tradeoff.

<k​ayabanerve:matrix.org> We're not planning a final decision in this meeting and doing a hard fork tonight.

<j​effro256:monero.social> Well yes, in the technical sense, the behavior of the spendability only changes after hard fork activation. The decision on the height isn't actually finalized until the fork code is accepted by nodes. The announcement is just a management of expectations, although it does signal a break in way that unlock_times are respected for a subset of transactions that *may* exist in the future

Rucknium: It sure does shine a bright light on centralization issues that so far were mostly left out of limelight, but always existed, and that may turn into a problem

IMHO

<r​ucknium:monero.social> We need to get to the next agenda item at least. Usually it's best to put the longest, most involved item last on the agenda, but I failed here :D

<j​berman:monero.social> I guess individuals should probably just never propose / discuss ideas to limit dos concerns? I don't understand this downside / discussion

<r​ucknium:monero.social> Let's do the next agenda item, then we can come back to this to maybe get to a rough consensus

<k​ayabanerve:matrix.org> I think this can be argued as HF planning and HF community consensus is as it always has been. I'm not too concerned about centralization here so long as any announcement on ignoring timelocks is properly worded.

<k​ayabanerve:matrix.org> Rucknium: oh I can take even more time with my topic

<k​ayabanerve:matrix.org> I won't leave you as having failed

<j​effro256:monero.social> Yes I do appreciate Rucknium for bringing the centralization issue, it shouldn't be taken lightly. My gut reaction is that it isn't *more* of a centralization issue than a regular hard fork, but I will certainly think about it

<j​berman:monero.social> (in this context I don't understand it)

<r​ucknium:monero.social> 4) CCS proposal: Audit monero-serai and monero-wallet gist.github.com/kayabaNerve/3723d0a3f2b62ef8ef00c0c4a574fb8e

<t​obtoht:monero.social> A multisig implementation is useful for user-facing wallet applications if sensible UX can be built around it.

<t​obtoht:monero.social> This has turned out be quite difficult to achieve with monero's current multisig code, for reasons in part because of inherent issues like its O(n!) complexity. Other problems are message transport, state management, UX design, recovery and handling of failure modes, and the mess that is wallet2.

<t​obtoht:monero.social> I haven't looked at this library or the FROST spec in detail yet, however the reduction in complexity, formalization of a standards-based protocol, as well as modularization of the code are all very welcome improvements.

<t​obtoht:monero.social> I have some questions (feel free to answer after the meeting):

<t​obtoht:monero.social> - Does this implementation require the use of a multisig-aware coordinator?

<t​obtoht:monero.social> - Does this library define a standard message format (so messages can be passed to other participants or a coordinator)?

<t​obtoht:monero.social> - Is there a potential path for `wallet2`-based applications to use this library specifically for multisig? (Just wondering if you see any problems with wallet projects adapting wallet2 to use this library.)

<t​obtoht:monero.social> - Does `monero-wallet` manage state or are wallets expected to handle this?

<t​obtoht:monero.social> - For my understanding of the library, are there any tests or documentation that show how a wallet would use this library to set up a multisig wallet and create a transaction proposal?

<t​obtoht:monero.social> - Does FCMP++ require changes to the library, and if yes, would it make sense to audit once those changes are ready?

<t​obtoht:monero.social> Some (minor) comments:

<t​obtoht:monero.social> A link to monero-serai and monero-wallet in the gist would have been helpful, it took me a moment to find where these repositories live.

<t​obtoht:monero.social> For reference: github.com/serai-dex/serai/tree/develop/networks/monero and github.com/serai-dex/serai/tree/develop/networks/monero/wallet

<t​obtoht:monero.social> The "monero-wallet" name is a bit unfortunate, as "It also won't act as a wallet, just as a wallet functionality library". Perhaps something like `monero-tx-utils` or `monero-wallet-lib` would have been more fitting?

<r​ucknium:monero.social> Thanks so much for your comments and questions, tobtoht

<k​ayabanerve:matrix.org> The DKG does encrypt its messages and no FROST messages need encryption. Message transport is solely authenticated channels if you want the ability to blame participants.

<k​ayabanerve:matrix.org> It is abstract however to whatever communication protocol you may want.

<k​ayabanerve:matrix.org> For the DKG, you do need consensus on the result. The DKG is modular. Right now, all that's implemented is PedPoP, yet the Bitcoiners proposed ChillDKG which achieves consistency.

<k​ayabanerve:matrix.org> One could implement that and then use that to remove the requirement of a consensus protocol.

<k​ayabanerve:matrix.org> I'm just speaking to further argue the modularity/design

<k​ayabanerve:matrix.org> The FROST code is uncoordinated. The library does define messages (without authentication). The FROST lib follows the IETF standard. The application to Monero obviously isn't IETF standard and is a bit bespoke however.

<k​ayabanerve:matrix.org> This doesn't just expose multisig TX signing. It also exposes multisig CLSAG signing. A wallet2 app could do everything on its end and solely call out for each CLSAG.

<k​ayabanerve:matrix.org> monero-wallet has no DB/DB API. It also doesn't define a transport layer, solely an API which must be met by a transport layer.

<k​ayabanerve:matrix.org> There are tests, there aren't examples at this library.

<k​ayabanerve:matrix.org> FCMP++ will cause changes. It doesn't make sense to delay the audit IMO. It makes sense to do a follow-up audit at that time.

<k​ayabanerve:matrix.org> Apologies for the lack of links to the source.

<k​ayabanerve:matrix.org> Considering that's the package name in the Rust ecosystem (not some global namespace), and it is the pieces to scan/sign/send Monero TXs, I find the name fine. `-lib` isn't convention in this ecosystem.

<k​ayabanerve:matrix.org> Also, this isn't just TX utils, and there already is monero-wallet-utils for extra features not present in monero-wallet directly (for whatever reason).

<j​effro256:monero.social> Would the parts of the codebase would be disjoint? IMO one nice property of audited files is to be able to SHA256 it and compare it directly to a hash in the audit report so that you know for a fact that no breaking changes have been added since the audit

<j​effro256:monero.social> Would the parts of the codebase be disjoint? IMO one nice property of audited files is to be able to SHA256 it and compare it directly to a hash in the audit report so that you know for a fact that no breaking changes have been added since the audit

<k​ayabanerve:matrix.org> This is a living codebase and it absolutely isn't expected to meet that criteria.

<k​ayabanerve:matrix.org> The library is at the point the API shouldn't change, it should have all the features necessary, and it should be safe.

<k​ayabanerve:matrix.org> That's why it's being proposed for audit.

<k​ayabanerve:matrix.org> To keep exact file integrity would require we never add further documentation however. It's not feasible.

Maybe you could make a public walkthrough of the code? Like UkoeHB did with his Seraphis library? So people would get some nice first impression what this is all about?

<k​ayabanerve:matrix.org> The plan is to audit a git commit so people can see the differences via git. That should allow the same degree of auditability.

Because it's a bit hard to support, or not, the idea of an audit for this with next to no idea what it is :)

<k​ayabanerve:matrix.org> I'm actually unsure what that example is.

<k​ayabanerve:matrix.org> monero-serai underlies Cuprate and is a complete reimplementation of the Monero transaction code in Rust.

It was an interactive (Jitsy?) walkthrough with audio explanations about key points of the code.

<k​ayabanerve:matrix.org> monero-wallet is a reimplementation of scanning/signing/sending transactions in Rust built around monero-serai.

I think jberman attended that, and may remember

<k​ayabanerve:matrix.org> It's to some degree a wallet2 alternative. wallet2 manages itself, while this expects the app to manage it (offering greater flexibility), but this still offers all the high-level API components necessary to send/receive Monero.

<k​ayabanerve:matrix.org> Notably, it also includes a multisig protocol which tobtoht already independently noted the theoretical merits of.

<k​ayabanerve:matrix.org> And sorry, I'm not trying to state everything here/now, in this very moment, and talk over people. I'm just trying to respond with as much clarifications as I can.

<j​effro256:monero.social> How dare you talk about your own library

<s​yntheticbird:monero.social> This meeting is sponsored by monero-wallet

<k​ayabanerve:matrix.org> I'll also be honest and say I'm unsure I can do a video walkthrough and unlikely to. I'd prefer to add more examples to the codebase to achieve documentation in the first place, yet I'll also note I get about 10 fps on my laptop so I'm pretty sure video recording isn't possible.

<r​ucknium:monero.social> Disclosure: I statistically verified that `monero-wallet`'s decoy selection distribution matches that of wallet2 last year in exchange for 1 XMR. At least I think it was last year.

<j​effro256:monero.social> Was that after the 10-block-lock DSA bug ?

<k​ayabanerve:matrix.org> I think I have a spare laying around I can boot into a live image on? It may not have a working wireless card in it though 🤔 Suffice to say, my setup is sufficiently insane video recording isn't great for me.

<k​ayabanerve:matrix.org> jberman has also done their analysis of fingerprinting vectors, including the DSA. They were critical for their role in TX extra.

I think some well selected sample code using the libraries would go a long way towards giving an impression about power and extent of those libraries

<k​ayabanerve:matrix.org> For example, who here knew you can specify multiple TX pub keys and wallet2 will scan for all of them?

<j​berman:monero.social> Disclosure on my end too: @kayabanerve has paid me to work on monero-wallet. I put a decent amount of work into it to reduce fingerprints to wallet2, and did a general pass-through review

<k​ayabanerve:matrix.org> Yet wallet2 will only scan the first vector of additional keys specified in TX extra.

<k​ayabanerve:matrix.org> It's this exact type of oddities which we've extensively worked to minimize. It truly has been worked on for years.

<j​berman:monero.social> Personally I think it would be quite a bit of work to make wallet2 compatible with monero-wallet's general flow. I don't know if that would be a feasible approach, except potentially in the isolated components like CLSAG signing? But then, I'm not sure how everything else would work for multisig

<k​ayabanerve:matrix.org> Oh. jberman also got the fees to match exactly.

I think we have tons of questions all at once with these 2 libraries. Switching to this new type of multisig for Monero in general being only 1 of them.

<j​berman:monero.social> Unless maybe there is a way to lean on wallet2 for scanning, and then monero-wallet for DKG setup / constructing txs? I would assume not, and to get monero-wallet working in a functional end-wallet, I imagine would require a full implementation of wallet state handling

<r​ucknium:monero.social> jeffro256: Yes. December 2023: serai-dex/serai #384#issuecomment-1870597406

<k​ayabanerve:matrix.org> Importing monero-clsag (a subset of the library linkable on its own without pulling in all other components) into a wallet2 app should be quite feasible IMO.

<k​ayabanerve:matrix.org> The greater note is on the value in the academia done here and proposed however.

Is there any idea yet about the rough magnitude of work that the proposed audit would require?

<k​ayabanerve:matrix.org> wallet2 apps don't have to adopt monero-clsag. The theory here, once proven, would allow C++ implementations to be done without repeating the prior multisig drama.

<k​ayabanerve:matrix.org> The quote is expected to be 750-1000 XMR.

<k​ayabanerve:matrix.org> I'll also note the current multisig in wallet2 still isn't proven. This isn't just proving an alternative protocol. It'd be the first implemented and proven Monero multisig.

<j​effro256:monero.social> But to be fair, the monero-clsag won't be useful for multisig after the FCMP fork right? Unless it is compatible for syncing key images with the current core repo multisig implementation?

<k​ayabanerve:matrix.org> I have no idea what you mean by "syncing key images".

<k​ayabanerve:matrix.org> I'm just unfamiliar with that wallet2 flow, sorry.

<k​ayabanerve:matrix.org> monero-clsag won't be useful after FCMP++. Any existing key image sync also won't be. Both will change.

<r​ucknium:monero.social> At this moment, I really like the idea of proving and auditing the FROST multisig. On the remainder, I wonder why it is more important to audit this library instead of `monero-ts`, -python, -php, or even Monero's native C++ implementation.

<j​effro256:monero.social> Current multisig implementation requires M participants in a M/N multisig wallet to come together to combine "partial key images". I'm assuming a similar technique is required for multisig in monero-clsag, but if the exact math isn't compatible, then it wouldn't carry over

<k​ayabanerve:matrix.org> The same premise applies jeffro256.

<k​ayabanerve:matrix.org> All of that will break with FCMP++, even whatever's currently in wallet2.

<k​ayabanerve:matrix.org> Here's why I'm still asking to do this.

<k​ayabanerve:matrix.org> rbrunner: How long until the FCMP++ HF activation in your opinion?

"why it is more important to audit this library instead of" Interesting question

1 year? But not sure of the context of that question

<k​ayabanerve:matrix.org> I believe the most recent estimate I saw from you was Q4 of 2025.

<k​ayabanerve:matrix.org> I disagree with that estimate being likely, but it means I have to either:

<k​ayabanerve:matrix.org> 1) Delay Serai a year

<k​ayabanerve:matrix.org> 2) Deploy an unproven multisig for ~6-9 months and just pray nothing happens

<k​ayabanerve:matrix.org> The fact CLSAG will be replaced doesn't mean it isn't here now.

<j​babb:cypherstack.com> disclosure: cypher stack employee. I originally made monero-php years ago. recanman has been redoing it to reimplement monero crypto in pure php. MrCyjaneK bound wallet2 to PHP via the monero_c repo recently in order to provide the last missing pieces and prepare for FCMPs &etc. by outsourcing crypto to monero-project/monero

<j​babb:cypherstack.com> in my opinion we shouldn't allow these wrappers to handle crypto but rather rely upon the c++ we know and love and the rust we need. rust is much easier to build and build with for me so I prefer focusing on c++ and rust rather than all the other, higher-level languages

<k​ayabanerve:matrix.org> And that's my personal involvement with it. There are other multisig use cases which either aren't feasible due to the current multisig's failings, or are also YOLO'ing it.

<k​ayabanerve:matrix.org> Rucknium jberman jeffro256 Is it possible to audit wallet2?

<k​ayabanerve:matrix.org> Isn't a lot of it in a single 10k line file?

<k​ayabanerve:matrix.org> Doesn't it depend on epee, a bespoke never audited lib?

<r​ucknium:monero.social> ...exactly

<k​ayabanerve:matrix.org> I'm legitimately unsure it is feasible. If the Monero project can put forth a version of wallet2 to audit and have an auditor who doesn't look at us like we're insane to ask, I'd support such a CCS.

<r​ucknium:monero.social> My wallet2 question was a little rhetorical since I have seen tobtoht say that a wallet2 audit right now would be very hard because it is spaghetti. But do we know the current Monero tx functions are working correctly?

<k​ayabanerve:matrix.org> I have built a library I believe can be audited. I have prepared it for auditing. I have an auditor (Cypher Stack) finalizing their quote. I made a CCS.

<k​ayabanerve:matrix.org> Even if wallet2 could be audited, I'd treat it as a distinct topic.

<r​ucknium:monero.social> Won't part of the proposed audit be to check that the library does what the Monero C++ implementation does? There is cryptography, which is separate, and then other parts that need to be checked.

<j​berman:monero.social> wallet2 multisig still doesn't have security proofs for its relatively makeshift protocol, nor someone willing to carry it forward at the moment. getting it audited isn't the only task necessary to get its multisig across the line. monero-serai has implemented a peer-reviewed, widely known protocol for multisig, that is also orders of magnitude more performant than wallet2's multisig impl

<k​ayabanerve:matrix.org> The lib is tested to have the expect fee on every TX it makes. It's also been reviewed and cites links for all the weird quirks it has.

<k​ayabanerve:matrix.org> github.com/serai-dex/serai/blob/599…/monero/wallet/src/send/mod.rs#L321

What I currently have still trouble wrapping my head around it is libary use cases. Or is it alread "worth it all" just for Serai and any use cases beyond that just bonus, to put it bluntly?

<j​berman:monero.social> given resources at hand, I personally think monero-wallet is a clear choice for where to allocate continued effort and resources for multisig efforts

<k​ayabanerve:matrix.org> The tests do also test against monero-wallet-rpc.

<k​ayabanerve:matrix.org> github.com/serai-dex/serai/blob/599…orks/monero/wallet/src/scan.rs#L150

<k​ayabanerve:matrix.org> Just as a pair of examples of our citations to Monero which I do aim to demonstrate they do try to match behavior exactly.

<k​ayabanerve:matrix.org> Rucknium: The audit will be to confirm this code sane and that comes with some level of comparing to C++. It doesn't come with auditing the C++.

<k​ayabanerve:matrix.org> rbrunner: Cuprate.

Ah, yes, of course

<r​ucknium:monero.social> IIRC, kayabanerve has said Serai hasn't received Monero community funding. IMHO, if this full audit gets CCS funding, then that claim should change.

<k​ayabanerve:matrix.org> The CCS is actively funding a dependent of this, has been for several months, and they've received more in funding than I plan to ask for here.

<k​ayabanerve:matrix.org> Rucknium: NACK.

<k​ayabanerve:matrix.org> None of this code is Serai specific and monero-serai is planned to be transferred into monero-oxide after.

<k​ayabanerve:matrix.org> I'm fine saying the CCS paid for the audits of the Monero library Serai built. That doesn't change this isn't Serai proper.

More and more I come to believe that this is much bigger than just "Do we move this to CCS for funding?" We are talking about the future of the whole Monero codebase in a way.

Which is pretty difficult and is pretty far-reaching.

<k​ayabanerve:matrix.org> I see this as comparable to Cuprate.

<k​ayabanerve:matrix.org> It does potentially 'endorse' a completely non-wallet2 wallet which is notable.

<k​ayabanerve:matrix.org> But the academia is mutually beneficial and we aren't yet discussing ripping out wallet2's multisig.

<k​ayabanerve:matrix.org> That is a proposal which comes up occasionally but we're not there yet.

<r​ucknium:monero.social> rbrunner: That's my cue to move back to the question of whether there should be an ASAP announcement that the next hard fork will not honor custom timelocks after a certain date.

<k​ayabanerve:matrix.org> With FCMP++, monero-serai will share code with monerod however.

<s​yntheticbird:monero.social> rbrunner: Rust will eventually grow upon monero's lands.

<r​ucknium:monero.social> Since it seems that meeting attendees wanted a decision on that today

<k​ayabanerve:matrix.org> They'll both use the same FCMP++ set of libraries and the plan is for my FCMP++ libraries, in Rust, to handle multisig.

<k​ayabanerve:matrix.org> So FCMP++ multisig is Rustifying, and this provides a Rusty alternative for CLSAG.

<j​berman:monero.social> There shouldn't be an ASAP announcement that next hard fork will not honor custom timelocks after a certain date

I didn't understand meeting sentiment to long for a timelock decision today, and I would like to come back to it in 1 week, after some thinking it over

syntheticbird: Our C++ codebase is already rusting all on its own, thank you very much :)

<j​berman:monero.social> @jeffro256 is going to look more into numbers of timelocked outputs. I or @jeffro256 can write up another MRL issue fleshing out the idea in a clearer/cleaner way. Then we can discuss it again and gauge sentiment to the idea. Imo if it gains rough consensus, it wouldn't need to be officially announced until the fcmp++ research is all audited / formalized, and honestly probably not<clipped message>

<j​berman:monero.social> til code is ready

<t​obtoht:monero.social> I continue to have concerns about Rust and its ecosystem, which I find are especially relevant for consensus level code, but I will detail those later in a comment under the fcmp++ integration PR (#9436).

<t​obtoht:monero.social> (And to be clear, my intent is not to NACK, but to make sure we understand its implications on supply chain security, build system complexity, long-term maintainability, cross-architecture reproducibility, bootstrappability, and third-party packaging and to make sure we have the necessary tools in place to maintain it.)

<r​ucknium:monero.social> Maybe the _option_ of not honoring custom time locks past a certain date is enough to deter a potential vandal. In a game theoretic sort of way.

<k​ayabanerve:matrix.org> I'm fine letting the monero-serai/monero-wallet audits marinate to next week yet I would like MRL to issue an opinion by the next community meeting if possible. If it's not, so be it, just an unfortunate delay in the bureaucracy.

<k​ayabanerve:matrix.org> I'll also note, rbrunner, the libs do have 100% documentation. I'll try to set up a hosted copy of the docs as that may be useful per your notes.

<r​ucknium:monero.social> Let's end the meeting here. Feel free to continue discussing things. Thanks everyone.

<k​ayabanerve:matrix.org> If anyone wants to locally see them, it's

<k​ayabanerve:matrix.org> git clone git⊙gc/serai-dex/serai

<k​ayabanerve:matrix.org> cargo doc -p monero-wallet --all-features -- --open

<k​ayabanerve:matrix.org> Rucknium: All topics took longer than their last :D

<k​ayabanerve:matrix.org> If anyone wants to locally see them, it's

<k​ayabanerve:matrix.org> git clone git⊙gc:serai-dex/serai

<k​ayabanerve:matrix.org> cargo doc -p monero-wallet --all-features -- --open

<k​ayabanerve:matrix.org> If anyone wants to locally see them, it's

<k​ayabanerve:matrix.org> git clone github.com/serai-dex/serai

<k​ayabanerve:matrix.org> cd serai

<k​ayabanerve:matrix.org> cargo doc -p monero-wallet --all-features -- --open

<k​ayabanerve:matrix.org> (Sorry to the IRC people for my edits of the above commands)

<j​effro256:monero.social> Great success

<j​effro256:monero.social> Thanks everyone!

<r​ucknium:monero.social> jberman: Let me put it this way. If the developers of a cryptocurrency stated that all coins sent to burn addresses would become spendable in the next hard fork, that would change the total effective supply of the cryptocurrency. Users would be free to upgrade or not upgrade to the hard fork, of course. The custom time locks issue isn't too different.

<k​ayabanerve:monero.social> I'll note again we kinda have to invalidate timelocks for the PQ migration.

<k​ayabanerve:monero.social> This is inevitable to a nontrivial degree.

<j​berman:monero.social> the issue I take with this comment is you characterizing the discussion today as "the developers of a cryptocurrency stated that <x is going to happen>"

<j​berman:monero.social> that isn't what happened nor what's happening

<c​haser:monero.social> kayabanerve: just curious, what is the critical point of interference between timelocks and PQ signatures?

<j​berman:monero.social> we discussed a dos vector and technically reasonable mitigation to the dos vector. we didn't say the mitigation is now set in stone and going to happen

<k​ayabanerve:monero.social> We need to allow a migration or the outputs will be burnt/available to steal. The migration will be to a PQ key. That PQ key may be held by a distinct entity, meaning a transfer did occur prior to the timelock expiry.

<k​ayabanerve:monero.social> We then either have to maintain the timelock, despite allowing a transfer, or drop it as we don't care.

<k​ayabanerve:monero.social> The best solution is to just remove to the no-transfer restriction we can't actually enforce.

<j​berman:monero.social> I think that would be reasonable logic to invalidate timelocks at a PQ migration fork. I wouldn't push to invalidate timelocks today for a future fork

<s​yntheticbird:monero.social> pardon me PQ meaning?

<j​berman:monero.social> post-quantum

<s​yntheticbird:monero.social> I must have missed an episode. We're doing PQ already ?

<c​haser:monero.social> kayabanerve: a-ha. checks out, thank you.

<j​effro256:monero.social> Not as this moment, kayaba is just making the point that we will have to invalidate unlock times at some point assuming we do a PQ migration

<s​yntheticbird:monero.social> Ah ok thx make more sense

<s​yntheticbird:monero.social> so excited to share my 3MB McEliece address to receive my piconeros.

<c​haser:monero.social> base85-encoded Carrot addresses, here we go

base85?

<k​ayabanerve:monero.social> jberman: We won't be ideological purists about it then so there's no point in being it now is the argument. I'm not arguing for invalidation now. Solely justifying an ignore height (as those will be 'invalidated').

<c​haser:monero.social> rbrunner: to save on screen estate (half-joking). maybe bech85 (doesn't exist yet) so there's error checking. notably higher bases seem dangerous to me.

<s​yntheticbird:monero.social> how is it more dangerous?

<c​haser:monero.social> those would use non-ASCII characters, which may cause loss of data during encoding/decoding when passing through certain environments.

<s​yntheticbird:monero.social> oh ok

<c​haser:monero.social> on a more serious note, the conservative choice for PQ so far seems to be SPHINCS+ (gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a), which has public key sizes between 32--64 bytes, depending on the targeted security level. so I *guess*, even with a base32-variant encoding, addresses wouldn't be colossal.

<s​yntheticbird:monero.social> ah ok seems fine. I've experimented with it recently (as it got standardized) its performance are kinda shocking (in the bad sense).

<s​yntheticbird:monero.social> in debug mode sphincs signature could take several seconds to complete

<s​yntheticbird:monero.social> release mode max 2 seconds.

<a​surar0:monero.social> These numbers in release mode seems unrealistic. I've also experimented with several post-quantum signature crates recently. If taking SPHINC+SHA2+256s (the slowest algorithm available in my tool) keypair generation, signature generation, and verification are all subsecond operations. I'm using PQClean implementation. Tool repository here: github.com/Asurar0/mikomikagi

<s​yntheticbird:monero.social> ok ill test. i dont remember which crate i used

<a​surar0:monero.social> edit SPHINCS not SPHINC

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: SPHINCS+ isn't a good choice though

<k​ayabanerve:matrix.org> it'd require an interactive transfer protocol or it'd require wrapping in a commitment where we do a ZK proof opening the commitment and verifying the SPHINCS+ signature

<k​ayabanerve:matrix.org> At that point, we can use a SHA2 hash as a public key and collapse all of SPHINCS+ to that.

<k​ayabanerve:matrix.org> My guess is we end up on Ajtai commitments with a combination of MSIS and (some variant of) LWE at this point of time.

<s​yntheticbird:monero.social> we're cooking home made post quantum algorithm now?

<c​haser:monero.social> kayabanerve I was unaware of that limitation, happy to learn more. I was thinking along the same lines as SyntheticBird, will that require creating a custom crypto scheme? (not that I'm entirely opposed to that.)

<k​ayabanerve:matrix.org> SyntheticBird: We'll need to develop a PQ composition when the time comes. That PQ composition cannot solely rely on SHA2. If we end up relying on LWE for the composition, we don't benefit from choosing a slower, less functional signature without LWE.

<k​ayabanerve:matrix.org> We need a signature scheme where we can re-randomize the public key though.

<k​ayabanerve:matrix.org> So we open the commitment to get the underlying key, then output said underlying key with some rerandomization. Then we do a traditional PQ signature verification.

<k​ayabanerve:matrix.org> Or we remove the membership/spend-auth proof delineation and the commitment opening itself is spend-auth.

<k​ayabanerve:matrix.org> cc chaser too, ofc

<k​ayabanerve:matrix.org> If we put a SPHINCS+ key in a commitment on-chain, yet we can't re-randomize the key, then yeah, you have to verify the SPHINCS+ signature in ZK. Even an interactive protocol is insufficient for the necessary privacy properties.

<k​ayabanerve:matrix.org> You could technically still achieve membership/spend-auth separation? You'd produce a SPHINCS+ signature, then make a proof opening the rerandomized commitment from the membership proof and verifying the signature. So sorry, it is possible, it's just a bad idea.

<k​ayabanerve:matrix.org> It adds a massive ZK proof (which won't be on the same conservative assumptions) solely because a non-rerandomizable scheme wasn't chosen.

<s​yntheticbird:monero.social> didn't understand the whole thing not gonna lie but i got the important line. 👍️

<s​yntheticbird:monero.social> lines*

<c​haser:monero.social> kayaba, thank you for expanding on that. are there other routes? tevador unfavored CRYSTALS-Dilithium because it relies on lattice hardness assumptions. this is the first time I hear about Ajtai commitments, and my uneducated guess, based on the name, is that they have *something* to do with lattice-based crypto. I don't know about the re-randomizability though in CRYSTALS-Dilithium.

<d​iego:cypherstack.com> So...

<d​iego:cypherstack.com> if Cypher Stack was to do some research after Carrot pro bono.

<d​iego:cypherstack.com> What would you all want us to look at? :)

<s​yntheticbird:monero.social> P=NP obviously

<s​yntheticbird:monero.social> (jk i'm curious about the next chain of event)