Monero (XMR)

Monero (XMR) - The secure, private, untraceable cryptocurrency that keeps your money confidential. Grassroots. Open source.

[Monero (XMR) @monero]

The cryptography implementation for Full-Chain Membership Proofs (FCMP++) has successfully been audited by Trail of Bits!

'The review produced six informational findings. Zero high, medium, and low-severity findings were discovered.'

[MAGIC Grants @MagicGrants]

MAGIC Grants recently had @trailofbits, a leading cybersecurity and research firm, audit certain cryptography for Monero's forthcoming FCMP++ upgrade. This upgrade will substantially increase the privacy of Monero transactions.

Read more: https://t.co/PnlmY3TIB9

[Monero (XMR) @monero]

A Monero Meetup will take place in Krakow on August 21!

[OrangeFren.com @OrangeFren]

Thanks to @cakewallet we're organising a meetup in Kraków 🇵🇱 this Friday!

Join us for bowling 🎳, pool 🎱 and a chat about Monero 🧡

Meetup is taking place in Forum - the chosen venue for MoneroKon 7

Sign ups:
https://t.co/XTqkASAxLF
https://t.co/rrTlLAH58Y

[Monero (XMR) @monero]

The Monero Research Lab has provided an update on Full-Chain Membership Proofs (FCMP++)!

'Full-Chain Membership Proofs prove the output spent is one of any output on the chain, effectively removing all of these risks. This means every input goes from an immediate anonymity set of 16 to 100,000,000.'

[Monero Research Lab (Unofficial) @MoneroResearchL]

jberman reported that the Rust FFI PR has been merged into upstream master and that the next item on the FCMP++ integration list is monero-project/monero #10360, the final PR from the Phase 1 audit. For Phases 2 and 3 he preferred continuing internal reviews and merges, with audits to follow once the code is fully in (or Phase 2 audited after its code lands). jeffro256 updated the planner at https://t.co/RPDlO52Ap8. The largest remaining Carrot-side blocker is the LGPL licensing of mx25519 (https://t.co/knPGIxDCaf). Discussion focused on LGPL section 6 compliance (providing a link to the release tag commit), possible monero-site changes, CoC compatibility, effects on downstream wallets and hardware-wallet integrations, the existence of at least one other LGPL dependency (polyseed), and the feasibility of a permissive reimplementation. tevador declined to relicense and stated that the practical restrictions are mild (primarily adding the license text to the release archive). Views ranged from accepting LGPL in order to move forward quickly to concerns about added complexity, technical debt and downstream burden. No consensus was reached; the licensing discussion was left open and suggested for the No Wallet Left Behind agenda or further GitHub comment. On the audit side, the Least Authority helioselene review is near completion while quotes are still needed for the remaining research-task audits.

jberman: The Rust FFI PR was merged into upstream master (hooray), next on the FCMP++ integration list is: https://t.co/f0DkfyWdWS
jberman: That is the final PR from the Phase 1 FCMP++ integration audit
jeffro256: I have updated the planner here: https://t.co/RPDlO52Ap8
jeffro256: OOps that's already linked
jberman: For Phases 2 & 3, right now I'm thinking it would be best to just keep going reviewing on our end and merging code, and once all code is in we audit then (perhaps we get Phase 2 audited once all that code is in). I think that would be most efficient
jeffro256: Biggest blocker on the Carrot side seems to be licensing around mx25519: https://t.co/knPGIxDCaf. tevador has mx25519 licensed under LGPL, which has some restrictive terms.
jberman: No major update at the moment on the final Research Task audits. The Least Authority helioselene audit is very close to the finish line
jeffro256: There's some discussion around how exactly Monero will comply with the terms in section 6 of LGPL v3: https://t.co/N7FZswBIRN. IDK if anyone has something to throw in here, because it doesn't seem to be going anywhere quickly...
jberman: And we still need quotes for divisors impl audit rd. 2 + fcmp-plus-plus lib audit
jpk68: jeffro256: It does seem like this would complicate things a fair bit, which would be quite inconvenient. Adopting LGPL dependencies, I mean
jpk68: The amount of complexity surrounding this upgrade is already pretty extreme
jpk68: Downstream users of Monero code would also be affected by this (i.e. wallet applications)
tevador: The "restriction" of LGPL § 6 would imply we would need to provide a link to the tag commit the release was built from. Which is hardly a restriction.
jpk68: tevador: You mentioned that you didn't want to relicense your code after companies made proprietary forks of RandomX code.
tevador: Example: https://t.co/ty6zmPxr77
jeffro256: Yeah, that does involve some changes to monero-site, though.
jpk68: I'm wondering how the same concern applies to general cryptography code, rather than PoW
vtnerd: the primary objective of the lgpl is to force changes to mx25519 to be made public … ?
jpk68: Yes, but how is that practically relevant here? I can see how it is for RandomX
tevador: The exactly same thing applies to a Curve25519 library. If someone makes optimizations, we want to be able to upstream them.
vtnerd: I guess a wallet could be made faster in secret, similar to the issue in randomX
slowbeardigger: In xmrpay-carrot I already use a BSD-3 Rust implementation based on curve25519-dalek that matches the upstream CARROT vectors.
slowbeardigger: It only covers the receiver side CARROT operation for now, not the full mx25519 API.
slowbeardigger: would a permissively licensed rust implementation be useful, or does Monero specifically need C/C++?
vtnerd: c/c++ is more useful to the project I think, but opinions may differ
tevador: I'm pretty sure mx25519 is faster than curve25519-dalek
tevador: But both are usable for a wallet implementation
jeffro256: Espeially after considering Rust FFI
jeffro256: *Especially
slowbeardigger: hmmmm
slowbeardigger: what about a small portable BSD-3 C/C++ implementation be useful as a starting point if it matches the full unclamped API and existing vectors, or would optimized amd64/arm64 backends be required from the start?
slowbeardigger: just wondering if I can be of any help
vtnerd: this is assuming we are rejecting lgpl for some reason, it doesn’t seem to be a clear consensus on that
jeffro256: If you can get a portable implementation as fast as the amd64x version, I'd be impressed
tevador: A portable permissively licensed implementation could be made quite easily from the ref10 public domain code. But it's quite slow.
vtnerd: every wallet is open source already, if Im not mistaken
tevador: LGPL is open source.
slowbeardigger: jeffro256: I’ll try my best
vtnerd: I meant a wallet trying to use mx25519 but closed source somehow. I’m just not seeing any reason to worry about lgpl but maybe Im missing something
tobtoht: LGPL § 6 is not the only restriction and its restrictions would apply to all downstream projects, not just Monero.
tobtoht: LGPL is incompatible with the CoC: "All contributions to the project source code ("patches") MUST use the same license as the project."
jpk68: This is my point, we have already had enough trouble trying to get, for example, hardware wallet companies to integrate Monero
jpk68: Making licensing matters more complicated is shooting ourselves in the foot
slowbeardigger: I’m not assuming LGPL will be rejected. I’ll treat this as a small benchmark experiment first, compare it against the portable and amd64x implementations, and only suggest it if the result is actually useful…
slowbeardigger: I’ll start working on it
tevador: The CoC is clearly meant for other cases, like someone submitting a random patch under GPL.
tevador: AFAIK we already have at least one LGPL dependency
jpk68: Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically
jpk68: IIRC the only "copyleft" library we use currently is ZeroMQ, which is MPL
jpk68: That's somewhat less restrictive compared to LGPL
tobtoht: "The CoC is clearly meant for other cases" Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically
jeffro256: It would prevent modifying mx25519 itself, and not publishing the modifications, which is the point
rucknium: More discussion on this issue?
jeffro256: Ideally, we should figure this out soon, because it is a blocker for Carrot and Polyseed support
rucknium: Can the licensing discussion be moved to No Wallet Left Behind meetings or should it stay here for next week? Or moved back to GitHub?
jberman: tevador: do you see yourself budging on this issue and relicensing?
tobtoht: I will honor a vote
jeffro256: tobtoht: Since we have maintainers and approval processes, it is always at our discretition to block the changes that are superfulously adding non-permissive licensing for their own sake. I don't believe that Polyseed and mx25519 are those cases.
jeffro256: We will need to do some infra work on the monero-site side to support LGPL license terms. Is someone willing to make those changes? Also, we need to implement a license command or something along those lines correct?
jeffro256: To display the license body from the object code
jeffro256: rucknium: If the relevant people will join NWLB on Monday, then it could be moved there
jberman: my opinion on this is whatever moves this forward as fast as possible, I don't have a strong opinion on the license discussion itself
jberman: I think we should move on and if tevador wants to add to above tevador can
tevador: jeffro256: AFAIK we could just add the license file(s) to the release archive.
tevador: I have already explained why I'm not going to relicense.
jberman: ok, if tevador isn't going to relicense then I think let's just find a way to move forward with that
tobtoht: My personal opinion is that we should not burden every downstream ecosystem project with a restrictive license.
jberman: I think that's a fine opinion but we're stuck at an impasse here and I think it's best we move forward with it
tevador: The "restrictions" of LGPL are quite mild, even for closed-source projects that use the library.
UkoeHB: I am also against restrictive licenses both on principle and pragmatically (how much time wasted already on this? MIT gets no such drama). Is it possible an LGPL fork will just patent any changes they make, rendering the whole endeavor meaningless?
jeffro256: What exactly is the burden for downstream eco? That they must point to the Monero source ? Does that resolve section 6 since our repo would point to mx25519?
tevador: AFAIK there was no issue until tobtoht started to dispute the license.
jpk68: I don't want to be annoying and keep insisting on not having permissive licenses (at the expense of delaying things), but I feel like it's not a great idea to keep making non-ideal decisions, causing later technical debt, for the sake of finishing things faster
jeffro256: TBF looking over license terms is exactly what we need to avoid licensing issues ...
jpk68: At some point, one has to wonder how many concessions we're willing to make (Rust, LGPL, etc.) just to jam things through quicker
jberman: in this case I don't think there is much room for significant issues either way and both sides raise fine points
jberman: yes yes just to jam things through quicker than the 2 and a half years this has taken
rucknium: Given tevador 's statements, isn't a clean-room reimplementation of mx25519 the only way to avoid the LGPL in the Monero codebase? Anyone want to do that? If no, there seems to be only one option.
jpk68: jberman: Rewriting FCMP++ code in C/C++ would probably take longer than using the Rust library, no?
jberman: absolutely not
tevador: AFAICS the only change that would need to be made is to add the (L)GPL text to the release tarball. The rest is already solved.
jberman: sorry, absolutely yes*
sech1: Any code rewrite will require another code audit
jeffro256: tevador: Does does downstream have to do this if they use Monero as a library, instead of downloading releases?
jpk68: My point is simply that we shouldn't keep making compromises which will incur future technical debt under the excuse of saving time. In other words, I agree with tobtoht here
rucknium: IMHO, this issue should go on No Wallet Left Behind's agenda next week.
tevador: jeffro: It depends if they use the part that links to mx25519, then they have to also include the license file.
https://t.co/S89lk6OB6t

[Monero (XMR) @monero]

Seth for Privacy recently joined MoneroTalk to discuss Cake Wallet and Monero!

'Self-Custody Best Practices, Cake Wallet, and Monero with Seth for Privacy'

[MoneroTalk @MoneroTalk]

Self-Custody Best Practices, Cake Wallet, and Monero with Seth for Privacy https://t.co/bq9i5Kx4a1

[Monero (XMR) @monero]

A new version of Cuprate (an alternative and independent Monero node software written in Rust) has been released!

'With default settings, users with fast enough internet can expect to sync the blockchain in an hour.'

[SyntheticBird @SyntheticBird_]

Cuprate 0.1.0-preview: Kesterite is released! You can now connect your wallets to Cuprate nodes to sync and broadcast transactions. See our detailed blog post on the performance improvements of Cuprate over monerod in wallet syncing. (Please read it)

https://t.co/bGojY2JCBb

[Monero (XMR) @monero]

Tendermint (the consensus protocol for Serai DEX) has been released!

Serai is an innovative DEX that will offer a liquidity-pool-based trading experience for Bitcoin, Ethereum, DAI, and Monero!

[Serai DEX @SeraiDEX]

Serai has published the latest version of our implementation of Tendermint! We've also written a blog post discussing how the Serai network architects its consensus, how we actually achieve consensus, and all of the design considerations made for our implementation of Tendermint.

[Monero (XMR) @monero]

The MAGIC Monero Fund has started a second fundraiser to further increase Monero's fuzzing harnesses!

'Fundraiser to Bolster Monero's Security Through Automated Testing'

[MAGIC Grants @MagicGrants]

The MAGIC Monero Fund is 43% towards its goal to further improve Monero's automated testing (fuzzing) harnesses for increased security! Learn more ⬇️

https://t.co/E0Tl8Q7Wuk

[Monero (XMR) @monero]

The full release can be found below ⬇️

https://t.co/ujvaQWhwP7

[Monero (XMR) @monero]

We're excited to announce that GUI v0.18.5.2 'Fluorine Fermi' has been released!

'This release fixes wallet generation during first use.'

[Monero (XMR) @monero]

Emanuele Scala recently joined MoneroTalk to discuss Bulletproofs*!

'How Emanuele Scala’s Bulletproofs* Research Could Make Monero Transactions Smaller, Faster & More Private'

[MoneroTalk @MoneroTalk]

How Emanuele Scala’s Bulletproofs Research Could Make Monero Transactions Smaller, Faster & More Private https://t.co/chqUHgvYrz

[Monero (XMR) @monero]

The Monero Research Lab has provided an update on Full-Chain Membership Proofs (FCMP++)!

'This would shorten the overall timeline under cautious optimism.'

[Monero Research Lab (Unofficial) @MoneroResearchL]

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 https://t.co/puvN7Vc3pk 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: https://t.co/WSb9YwDDz4
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: https://t.co/ej4hA2v1km
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: https://t.co/tVjcXqGUCO
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: https://t.co/VCJUsCco4A. 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.
https://t.co/gn6mavcTrx

[Monero (XMR) @monero]

The 256th issue of the weekly Revuo Monero has been published!

[Revuo Monero @revuoxmr]

We're pleased to share Revuo #Monero Issue 256: April 12 - July 16, 2026 is now available!

https://t.co/eZW7RrpLMM

[Monero (XMR) @monero]

The Monero Research Lab has provided an update on Full-Chain Membership Proofs (FCMP++)!

'Full-Chain Membership Proofs prove the output spent is one of any output on the chain, effectively removing all of these risks. This means every input goes from an immediate anonymity set of 16 to 100,000,000.'

[Monero Research Lab (Unofficial) @MoneroResearchL]

jberman reported progress merging integration code upstream but solid advancement on major beta stressnet items, stating FCMP++/Carrot code is in good shape and does not need to block mainnet. UkoeHB is finishing the final multisig test. jeffro256 can now rebase the wallet knowledge proofs PR after the recent merge of seraphis-migration/monero #424. Hardware wallet work is close to completion thanks to jeffro256, with Ledger and Trezor evaluating it. The helioselene audit is ongoing, with internal discussion on the next circuit/gadget audit round.

jberman: * Still slowly making progress on getting integration code merged upstream
jberman: * Making progress on the major beta stressnet items, however, I would stlil say the beta is in a state where FCMP++/Carrot code doesn't need to be blocked from mainnet aka it seems to be in a good state
jeffro256: As for the task list , since shttps://github.com/seraphis-migration/monero/pull/424 was merged and reviewed (thanks Ukoe), I can rebase the wallet knowledge proofs PR , and chug along with that
jberman: * UkoeHB has mentioned for multisig he has 1 last test he's working through
jberman: I don't have an update on what's next with hw wallets
ofrnxmr: Also, plowsof performed wallet sync and cold signing on mobile wallet for stressnet
jeffro256: I keep getting messages that the companies are looking jnto it, but so far nothing has materialized
jberman: hot/cold wallet stuff seems pretty close to the finish line as well thanks to jeffro256
jberman: helioselene audit is still ongoing, and we're still discussing the next steps for another audit round on the circuit + gadget ipml internally
neptunian: jeffro256: Which companies are looking into it if I may ask?
jeffro256: Ledger, Trezor
plowsof: ofrnxmr yes , these transactions where all signed offline via DataHoarders stressnet payments explorer https://t.co/By8TgZVM3w and vtnerds lwsf carrot branch
rucknium: plowsof: Thanks. Does that mean that the code that we know works is Go code?
UkoeHB: Yes working on multisig test. wallet2 is quite poorly designed for testing.
plowsof: afaict yes : for the end user - the difference is after you import the signed transaction set - there is another 10-20 seconds of work that is done (building the tree and things jeffro would know about) but thats all. signed/unsigned tx sizes are just as small as wallet2 tx's
https://t.co/Bvd0xHPA2t

[Monero (XMR) @monero]

The full release can be found below ⬇️

https://t.co/T2KGDXC9GW

[Monero (XMR) @monero]

We're excited to announce that GUI v0.18.5.1 'Fluorine Fermi' has been released!

'This recommended release includes a large number of bug fixes.'

[Monero (XMR) @monero]

The full release can be found below ⬇️

https://t.co/PpkynHS7t8

[Monero (XMR) @monero]

We're excited to announce that CLI v0.18.5.1 'Fluorine Fermi' has been released!

'This recommended release includes a large number of bug fixes.'

[Monero (XMR) @monero]

The Monero Research Lab has provided an update on Full-Chain Membership Proofs (FCMP++), with FCMP++ getting closer to mainnet!

[Monero Research Lab (Unofficial) @MoneroResearchL]

6. Any other business
Rucknium checked the status of remaining FCMP++ items needed before deployment. Major blockers: beta stressnet, research audit tasks (including possible extra round on circuits/gadgets), and multisig. Koe is nearly complete with multisig; Jeffro is nearly complete with hot/cold implementation, with a recent major change to carrot_core affecting dependent PRs. Hardware wallets remain the biggest open item pending vendor capacity. @cakewallet is preparing a stressnet build. plowsof and ofrnxmr discussed testing cold signing/airgap and mobile wallets on stressnet. Rucknium will add a recurring general FCMP update to future agendas.
v2.1 blocking tasks focused on a rare double-spend error (low priority; main issue is node failing to relay tx). jpk68 reported outreach to Trezor on hardware wallet support.

rucknium: 6. Any other business
rucknium: I want to check in on status of the last FCMP++ items needed before deployment.
rucknium: jberman: Do these reflect the current remaining items: https://t.co/rilGoCMakE, https://t.co/DcgcGG0miU
rucknium: Is there another list we should be looking at, too?
rucknium: Or anyone else can comment on the to-do list, too.
jberman: The remaining major blockers include:
1. Beta stressnet
2. Research Audit tasks
3. Multisig
4. Hot/cold wallets
5. Hardware wallets
6. Getting all code merged
jberman: That list reflects Research audit tasks. In addition to what's there, we've been discussing having another round of audits done on the circuit and gadgets impl (the equivalent area where Zcash had a hidden inflation bug)
rucknium: The counterfeiting bugs & flaws in other coins make me nervous, personally.
rucknium: They have always made me nervous, but there are more of them now. And more recent.
jberman: I would say that if beta stressnet continues running the way it's been running, that beta has demonstrably served its purpose
jberman: Koe is nearly complete with multisig
jberman: Jeffro is nearly complete with hot/cold impl, which I've also reviewed in depth thus far
jberman: Hardware wallets are probably the biggest question mark on the impl front at the moment. Not that we won't be able to complete it. But we've been waiting on the vendors to indicate they have the capacity to do it asap
ofrnxmr: jberman: plowsof should test the cold signing airgap stuff for fcmp++ (and mobile eallet migration in general)
jberman: And then on merging code: we're making incremental progress on that front. Crypto building blocks are making their way in. That's been/will be my first priority at this point
plowsof: creating an unsigned tx set + signing (if thats possible now, it will be great to try)
ofrnxmr: I think an impotant step on the way, is for mobile wallet to be tested on stressnet
jberman: Cake mentioned they're going to prepare a build for the beta stressnet, so that'll be nice
ofrnxmr: Cake said theyd thibk abt it in public, maybe confirmed it elsewhere>
ofrnxmr: Acx said he couldnt get monfluo to build for master, and monerujo didnt respond yet
rucknium: Should I create a general FCMP update item on future agendas, or is there no need?
jberman: plowsof: AFAIK jeffro256 is still finalizing the PR from my review comments, but once that PR is fully ready, will be able to test it (will link the PR in a sec)
jberman: rucknium: Sgtm
jberman: This is the development branch PR for hot/cold wallets: https://t.co/oDrJ2mJIl7
rucknium: jberman: I will do it.
jberman: And then that'll get pulled into beta once it's ready here: https://t.co/CYGbWL50VN
rucknium: jberman: Thanks for explaining the FCMP to-do list!
rucknium: Anything else anyone wants to bring up?
jeffro256: Yeah, I recently made a big change to the carrot_core lib here: https://t.co/oLBBpQkfCW. Now the hot-cold PR, and the knowledge proofs PR depend on it
jeffro256: Today I'm refactoring all the doc strings in my Carrot code so they can be parsed by Doxygen, and I'm reviewing Ukoe's review of carrot_impl
jeffro256: j-berman Should we mention blocking tasks for v2.1?
jberman: Sure, blocking task is me looking into rucknium's latest logs showing another double spend error running code that solves a bug that was contributing to the issue, but apparently there is still another bug causing it and needs further investigation
jberman: I haven't had the chance to dig into those logs yet
rucknium: How important is it to fully resolve the double-spend error? It is extremely rare.
rucknium: In terms of priorities
jberman: Not very, I'm not prioritizing it highly at this point (and have also had somewhat limited availability this past week), which is why I haven't gotten to it
jpk68: I contacted @Trezor on Twitter, trying to give them contact info. They responded and said their devs were already in contact, which seems to be... not true
rucknium: (Note to readers: "double-spend error" does not mean that the blockchain accepts a double-spend. The error occurs because the wallet software forgets that it spent a coin and then tries to spend the coin again. The node rejects the transaction with a double-spend error.)
plowsof: ideally the wallet would self correct, the outputs marked as double spent in the tx are then marked as such and the next attempt does not include them. is this not happening?
ofrnxmr: Its not
rucknium: We can end the meeting here. Thanks everyone!
jberman: The more pressing concern with the issue ATM is that the node isn't relaying the tx in the first place, so tx gets stuck in the node un-relayed. That's the core thing that needs to be fixed here
https://t.co/ddSFr5RB2z

[Monero (XMR) @monero]

The Monero Research Lab has provided an update on Bulletproofs*!

[Monero Research Lab (Unofficial) @MoneroResearchL]

An update on emsczkp’s CCS proposal for research into*Bulletproofs* (BP*/BulletproofsStar), a folding scheme for Bulletproofs that aims to asymptotically reduce verifier execution time to logarithmic across many proofs: Milestone 2 has been completed. jberman reviewed the revised paper and proofs, describing them as solid, and supported payout of the CCS milestone. He recommended a dedicated mathematical review once the work is finished (similar to the process used for FCMP++).

rucknium: Last time emsczkp discussed his progress. jberman intended to look at the revised paper IIRC.

emsczkp: I have nothing to add beyond what said during the previous meeting. It was great to see positive comments on socials

jberman: I haven't had a chance to dive, but the revised paper (and proofs) looks solid

neptunian: jberman: ++

jberman: I think once the work is complete, it'll make sense to get another maths review on it, similar to how we've done for FCMP++

jberman: But reiterating, looking like great progress, and exciting results! Well done emsczkp

emsczkp: thank you!

rucknium: Last meeting, emsczkp asked whether it is OK to payout Milestone 2 of his CCS at this point or if more review is necessary.

jberman: I'm a +1 on payout

emsczkp: rucknium: Exactly, thank you for the clarification

rucknium: emsczkp: When the paper is complete, do you intend to submit it to a peer-reviewed journal or conference?

emsczkp: rucknium: yes, that's the goal

rucknium: That wouldn't necessarily be as rigorous as MRL would like it, but it would be at least another set of critical eyes on it.

rucknium: I mean, if the results were to be used in actual production Monero code.

rucknium: I am +1 on payout too, but I have not tried to understand the paper. Any other opinions here?

emsczkp: Exactly, and I’ll work on a submission to the first major conference on the subject asap

rucknium: emsczkp: Thank you.

neptunian: emsczkp: Hope to see you at EUROCRYPT :-)

emsczkp: Thank you, community, for the support on this reseach , which I strongly believe in and it is a very long story to me

rucknium: luigi1111 luigi1111_ : FWIW, we have support in this MRL meeting to payout emsczkp Milestone 2 of https://t.co/Tp244BvGqe

rucknium: More discussion on this item?

rucknium: Thanks, emsczkp
https://t.co/3s33GS1tiC

[Monero (XMR) @monero]

A new version of Unstoppable has been released!

[Unstoppable | Privacy Wallet @unstoppablebyhs]

MAJOR MONERO UPGRADES in Unstoppable Wallet

We have some important upgrades for XMR experience!

- we have fixed a number of crashes that were there for a while but were hard to reproduce.

- added a PrivateAlps (new node provider for XMR)

- add the an option for the user to set node connectivity to "autoselect" among listed nodes. when activated the app will always connect to the fastest node on each session (expect it live in the coming update

- coin control for monero (expect it live in the coming update)

- buy/sell XMR via @THORChain DEX (goes live as soon as XMR lands on THORChain)