specific implementation Bulletproofs bug in Beam beam.mw/blog/news/hardfork-six

uh, was for lounge. oh well

<rucknium> MRL meeting in this room in two hours.

<vtnerd> Schedule conflict during the meeting so I'll give my updates now: finished fixing small bugs in lws and lwsf (Claude Report/review). Now working on updating all the serialization prs - there's been one review in particular that needs attention

<gingeropolous> dunno what i'll be doing at the time, my update - cluster work. stupid hardware being stupid

<sgp_> My only update is that the Helios/Selene review kicked off and will be returned later this month

<sgp_> The reviewer is Least Authority

<rucknium> Meeting time! monero-project/meta #1420

<rucknium> 1. Greetings

<articmine> Hi

Hello

Hello

<boog900> Hi

<jberman> waves

<rucknium> 2. Updates. What is everyone working on?

Still Polyseed, but now with the code ready for re-review

Me: I2P GUI integration, writing docs

<rucknium> me: Keeping stressnet stressed and some HackerOne work.

<rucknium> There were some updates posted right before the meeting.

<jberman> me: continuing with finalizing the audited FCMP++ integration PR's (we're approaching 1k lines of integration crypto code merged including tests), and more stressnet investigating

<rucknium> 3. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol).

<rucknium> Any discussion on this topic?

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<rucknium> The main machine I use to send tx spam has had some stability issues. @gingeropolous:monero.social referenced them in his update before the meeting.

<rucknium> But other users are spamming from their machines. Thank you!

<rucknium> Block sizes have gone back to being small because tx spam isn't enough to keep them large.

<jberman> Looking to get v2.1 out in the next day (solves windows GUI crash, marginally improves wallet refresh, and will hopefully solve those double spend errors for good)

<rucknium> I added a few new features to my xmrspammer package github.com/Rucknium/xmrspammer . With get.view.keys(), a user can get the view keys of their spamming wallets. Useful for seeing which of your spam wallets are getting txs confirmed if you submit your view keys to stressnet.p2pool.observer/payments

<rucknium> And kill.wallet.processes() will kill the monero-wallet-rpc processes associated with a set of wallets. Useful in case you don't want to kill all of the wallet RPC processes running on your machine.

<rucknium> Anything else on stressnet?

<jberman> Nothing from me, other than that seems like remaining hiccups seem to be uncommon upstream edge cases

<jberman> and FCMP++ / Carrot specific code seems to be holding up well

<rucknium> @jberman:monero.social: Glad to hear it. (I will ping you about something at the end of the meeting.)

<rucknium> 5. monerosim (github.com/Fountain5405/monerosim).

<rucknium> @gingeropolous:monero.social said he is working on some hardware issues in the Monero Research Computing Cluster. Thanks, @gingeropolous:monero.social ! Probably there is no further update on monerosim for this meeting.

<rucknium> 6. Any other business

<rucknium> I want to check in on status of the last FCMP++ items needed before deployment.

<rucknium> @jberman:monero.social: Do these reflect the current remaining items: seraphis-migration/monero #53 cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed

<rucknium> Is there another list we should be looking at, too?

<rucknium> Or anyone else can comment on the to-do list, too.

<jberman> Sorry, computer connection is spotty rn. Switching to mobile

<jberman> The remaining major blockers include:

<jberman> 1. Beta stressnet

<jberman> 2. Research Audit tasks

<jberman> 3. Multisig[... more lines follow, see mrelay.p2pool.observer/e/tOqe4pQLM3VoaHhN ]

<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:matrix.org> 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:matrix.org: AFAIK @jeffro256:monero.social 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: seraphis-migration/monero #52

<rucknium> @jberman: I will do it.

<jberman> And then that'll get pulled into beta once it's ready here: seraphis-migration/monero #358

<jeffro256> Hi, sorry I'm late

<jeffro256> Yeah, I recently made a big change to the carrot_core lib here: seraphis-migration/monero #424. 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

<rucknium> @jberman:monero.social: Thanks for explaining the FCMP to-do list!

<rucknium> Anything else anyone wants to bring up?

<jeffro256> @j-berman Should we mention blocking tasks for v2.1?

<jberman> Sure, blocking task is me looking into @rucknium:monero.social '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:matrix.org> 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 > <@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

<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:matrix.org> 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