Firo Intern

jberman reported continuing FCMP++ PR upstreaming (next PR approved), stressnet double-spend fixes, and plans to solicit a secondary audit of the Rust FCMP++ circuit/gadget code. Trail of Bits finished phase 1 (report pending review). jeffro256 proposed removing phases 2/3 as blockers for the initial HF code merge and binary release so those audits can run in the post-merge window, with a contingency to delay activation if needed. This would shorten the overall timeline under cautious optimism. HW-wallet support is not required for the core HF (non-HW interfaces complete; Ledger exploring a CCS). Code-freeze discussion favored 2–3 months of bug-fix-only merges before activation, prioritizing consensus/p2p over a full feature freeze. VRP scope was noted as overly broad. No hard objections; ToB report and a Gantt chart expected before next meeting. RandomX v2 daemon PR is ready and should fit. jberman: Unfortunately won't be 100% available for today's meeting, my update: continuing upstream FCMP++ integration PR's (the next PR was approved today) and squashing the rare stressnet wallet double spend errors (with rucknium's help, who's running the latest set of fixes for the error / observed issues while debugging) jberman: On FCMP++ research tasks: we're looking to solicit quotes on a secondary audit of the circuit and gadget impl in the Rust FCMP++ lib and possibly more code as well, next step is drafting a proposal and reaching out to firms jberman: No additional material change to report from last week on other FCMP++ items from my end beyond above jeffro256: So ToB is done with auditing phase 1. I don't know if j-berman has release the report publicly yet, I think that he wanted to do a pass on it before releasing it. Justin and I want to propose something to move the timeline up: remove phase 2 and 3 audits as a dependency for HF activation and binary release UkoeHB: Is hw wallet support mandatory for hf? Cause those are going to take a while. jeffro256: This doesn't mean that phase 2 and phase 3 audits wouldn't happen, but they would happen during the 6-month conventional/mandatory waiting period instead. jeffro256: No, at least not in the core repo. That's my opinion UkoeHB: Ok seems reasonable rucknium: Are there big technical challenges for HW wallet support, e.g. need to fit big objects on limited wallet RAM? jeffro256: The interfaces for HW devices on the non-HW side are done. Ledger is interested in making a CCS proposal to fund R&D on their side. jeffro256: rucknium: I've talked to Kayaba a bit about this a while ago, and IIRC most parts of the SA/L signing can be "streamed" like they are now with CLSAGs. But it does complicate the signing as compared to simply having all the needed parts in-memory rucknium: "remove phase 2 and 3 audits as a dependency for HF activation" has confusing wording, IMHO. rucknium: "HF activation" means the date that the HF occurs, to me. jeffro256: By "HF activation", I meant "HF activation code merge", sorry rbrunner: What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario? rbrunner: Or, can we "take back" the HF? rucknium: Here's a 2020 paper on HW wallets for Monero moneroresearch.info/119 Klinec, D., & Matyas, V. 2020, "Privacy-Friendly Monero Transaction Signing on a Hardware Wallet." Paper presented at ICT Systems Security and Privacy Protection. rbrunner: (As a result of the on-going audits and reviews) jeffro256: rbrunner: Then the date gets pushed back 6 - N months, and people have to re-download binaries, where N is the "remaining time" between problem finding and previous HF activation date rucknium: Last HF, the announced date was moved at least once. I don't think any HF binaries were released and then withdrawn. jeffro256: rbrunner: We can "take back" the HF before it happens if users/companies stay up-to-date on releases rucknium: Anyone who downloads the binaries and neglects to update will be stuck on a bad fork. rbrunner: Yes, as the possibly worst outcome, however unlikely jeffro256: Note that this is something that can happen anyways without audits, with such large update, and we should prepare for it regardless of auditing rucknium: That's a similar outcome for people who just never update and a HF happens. rbrunner: Right. rbrunner: Seems to me the community of Monero users must be pretty "forking aware" now rucknium: If only we could get Linux package managers to also be forking aware jeffro256: Phase 1 has gone well so far, and j-berman and I are somewhat confident that further finding by future audits would likely be mitigatable without causing a HF relative to the current state of the codebase, but it's absolutely possible. rucknium: Could you describe phases 2 and 3 for us, jeffro256? jeffro256: I'm extremely confident that phase 2 and phase 3 could complete within the 6-month convential waiting period. With these assumptions in mind, if we were to take a cautious optimism approach, we could merge the HF activation code before phase 2 and 3 audits complete, and shave months off the timline. jeffro256: Then we have a contingency plan in case the audit feedback requires a HF relevant to previous release rucknium: You say "the 6-month conventional waiting period" as if a 6-month waiting period has ever happened before :D jeffro256: Phases 2 and 3 are defined in this document: github.com/seraphis-migra… tevador: There should generally be at least a 2-3 month code freeze before the HF, if possible. articmine: rucknium: Sometimes I prefer they are not. I have had issues with Bitcoin and Linux package managers articmine: Never with Monero jeffro256: tevador before HF activation, correct? tevador: Yes, before the fork activation date. jeffro256: I think that that is certainly possible with the planned scopes of phase 2 and phase 3 jeffro256: I'm working on a Gannt chart today because the timing and dependencies is getting hard to describe in words jeffro256: But I wanted to toss the idea of not blocking the first HF-activated release with phase 2 and phase 3 and get feedback on that rbrunner: maybe "HF enabled release" or "HF ready release" ... slstmd: What was the exact definition of code freeze again? vtnerd: presumably there would be a branch at the very least rucknium: I went back and looked. The previous HF binary was released less than a month before the HF activation date: github.com/monero-project… rucknium: I don't mean to say that it's a good precedent to follow. But "conventional" 6-month period is probably not the right word. jeffro256: lol fair rbrunner: I think that was always "the idea" :) jeffro256: I was under the assumption that that was the target for previous HFs rbrunner: That collided sooner or later with harsh cold reality vtnerd: we should’ve created the branch earlier than the 1 mo, and “froze” changes, but I don’t recall now tevador: Code freeze means only bug fixes can be merged... but this rule has not always been followed. rbrunner: I think it's still a good idea, and maybe *this* time, swapping almost the whole technology stack, we should pull that through rucknium: The 2022 HF delay was about multisig IIRC rbrunner: And also with coin exploits popping up left and right ... rucknium: Do we need more time to discuss this, in this meeting? We can give people time to think. I hope the Trail of Bits piece can be published by next meeting, to provide more info. rucknium: Will there be a bounty on exploits against the the frozen code before the HF is activated? rbrunner: Something that goes beyond the usually offered bounties would be a first, as far as I know tevador: The Monero VRP states that "code in all branches; including the master branch and any release branch" are in scope rucknium: The VRP scope is wide. Maybe something special isn't necessary: rucknium: > This Vulnerability Response Process and subsequent bounty reward apply to the following: rucknium: > Code implementation as seen in the Monero Project GitHub repositories rucknium: > This includes code in all branches; including the master branch and any release branch rucknium: > Written research from the Monero Research Lab which dictates said code implementation rucknium: github.com/monero-project… rucknium: But the potential reward isn't defined well. jeffro256: tevador: Maybe we should reduce the scope to *current release branches... jeffro256: I don't care if there's a vuln in v0.12.0.0 that got fixed 5 years ago tevador: Yes, that scope seems overly broad rucknium: More on this agenda item? articmine: jeffro256: Does this include anything that is pre release, or in testing for release etc. jeffro256: Does anyone currently object to not blocking the first release with phase 2 and phase 3 audits ? articmine: I understand the case of clearly obsolete code selsta: fwiw it has never been an issue that someone argued about old release branches, but yes the wording should be updated jeffro256: If it's still in a PR, I think it shouldn't be in-scope for payouts. If it's pre-release, it will probably be in master. If it's a planned release, it will show up in a current release branch rbrunner: Right now looks like a calculated risk worth taking to me. articmine: Fair enough, I just feel we should be careful and precise with the language. rucknium: jeffro256: I would prefer to have the Trail of Bits piece published before making a call on that, but I won't "object" to it. jeffro256: That's fair, AFAIK it should be release before next MRL meeting jeffro256: *released selsta: I agree with jeffro's proposal, as long as it's timed up so that all audits complete in time before the HF activates, with a small buffer articmine: selsta: I agree tevador: "small buffer" should be at least 1 month rucknium: How soon, from today, is the expected HF code freeze, i.e. when would the 6-month clock start ticking? jeffro256: I'll also release my Gannt chart that I'm working, so we can have something more concrete than a collection of English chat logs to describe the timeline tobtoht: Are we still branching v0.19 from master to test Guix and other changes in master? jeffro256: rucknium: tevador were you talking about a pre-first-HF-enabled release code freeze, or a pre-HF-activation code freeze? selsta: tobtoht: I would say yes selsta: Polyseed looks more or less ready jeffro256: We should do that ASAP IMO tevador: I think the code freeze should generally precede the first release binaries jeffro256: Would that be a code freeze on consensus and node related code. For example, would multisig support / HW support / wallet knowledge proofs / other wallet-specific features be under this code freeze? selsta: what's the status from stressnet for txrelay v2? ready for v0.19? tevador: jeffro256: That's debatable, but generally you want to freeze all features before the release and focus on bug fixes vtnerd: yeah theres lws RPC changes for example that someone has to slog through (review) rucknium: selsta: I think we should get at least a week of more testing with the latest proposed fix of the double-spend issue, IMHO. jeffro256: tevador If we freeze all features, that would push back the HF activation by several months for features that could be developed in parallel IMO selsta: I have always disliked an overly strict code freeze jeffro256: I think that that kind of a freeze is simply too broad jeffro256: I would agree that p2p and consensus features should be frozen for some period of time before release tevador: non-consensus changes can go into .1 anyways jeffro256: I think that basic sending / receiving / syncing wallet features should be frozen before the first release too tevador: What is the expected timeline for the HF? Can RandomX v2 stil make it? jeffro256: But, respectfully, waiting for Trezor and Ledger to activate FCMP++ would be a mistake jeffro256: They don't move very fast rucknium: Isn't RandomX v2 already ready? sech1? tevador: It's ready but not on the daemon side AFAIK? rbrunner: That's also what I dimmly remember selsta: there is a PR for it on daemon side, jeffro wrote it selsta: RandomX v2 wallet related code is not developed yet but that doesn't require HF rucknium: Do any HW wallet manufacturers move fast? Could there at least be one sure to be ready for the HF? jeffro256: tevador: The expected timeline for the HF is what I'm trying to decide. RandomX v2 should be able to make it. I have this PR: github.com/monero-project…. I need to add back the tx count and update the flow charts in the documentation, if we are to keep it jeffro256: But besides that, the consensus changes are done jeffro256: I plan to integrate DoS-resistant header-only sync after #10038 is merged, but that shouldn't be a blocker to the FCMP++ release tevador: Thanks, I missed that PR jeffro256: rucknium: I'm trying my damndest jeffro256: It would probably help to have a bunch of people bug them, IDK rucknium: jeffro256: I know you are. Thanks. But would users have an alternative in time for the HF? selsta: realistically Ledger/Trezor will use LLMs to implement FCMP++ so I assume it won't take too long rucknium: oh no gingeropolous: i ponder if we should add things to make the codebase llm friendly rucknium: Maybe their revenue isn't great right now. rbrunner: Many, many comments help. Something we are proudly famous for :) rucknium: rbrunner: Is that sarcasm from you? rbrunner: Yes, of course ... rucknium: I think we should move the agenda along. Feel free to discuss this agenda item after the meeting. rbrunner: Well, not the comment bit. They do support the work of LLMs greatly, from the little I know so far sech1: RandomX v2 is ready and released, XMRig version with v2 support is also released. Monero doesn't have v2 support yet. #c695350" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

For @cakewallet, active sessions and downloads are still climbing as they have for the last 8 years. 📈

private staking acheived internally @endurfi