Monero Community Workgroup Meeting: November 23rd 16:00 UTC

[plowsof]

Location: Libera.chat, #monero-community | Matrix

Instructions for joining the monero.social Matrix server.

Time
16:00 UTC Check your timezone

Moderator: plowsof

Please reach out in advance of the meeting if you would like to propose an agenda item.

Proposed Meeting Items:

1. Introduction
2. Greetings
3. Community highlights
   News: Monero Observer - Revuo Monero
4. CCS updates
   a. Carrot animated video close
   b. CryptoCheckout WordPress plugin (for WooCommerce) & Shopify app close
   c. Monerotopia 2024 Marketing and Publicity pre-approved pending invoice
   d. Gingeropolous 1TB MRC upgrade
   e. v1docq47 - monerotopia 2024 voiceovers and working on xmr.ru
   f. Add monero-[serai, wallet] audit
5. Workgroup reports
   a. Dev workgroup
   b. Localization workgroup
   c. Outreach workgroup
   d. Events workgroup - MoneroKon 2025
   e. Website workgroup
   f. Policy workgroup
   g. Research workgroup
   h. Seraphis Migration workgroup
6. Open ideas time
7. Confirm next meeting date/time

Previous meeting including logs

Meeting logs will be posted here afterwards.

[plowsof]

Logs

< plowsof > Meeting in 1 hr #1113

< r​ottenwheel:kernal.eu > As long as you let one decide between persistent and stateless, I'm game. vthor

< r​ottenwheel:kernal.eu > Good luck figuring out how to do persistent though lol, will be interesting to see.

< vthor > rottenwheel: I don't like really the thought to safe the seeds on the same microSD card - although it is probably the cheapest option, it is not the best. On my research for NFC payment on weak hardware I found cheap SPI secure elements and SPI flash, which could be sourced in quantities of 100 for below $5.

< r​ottenwheel:kernal.eu > vthor the more you talk about ways to implement persistent state for XMRSigner, the less I like the idea, and I already oppose and disagree with it 100% as-is...

< vthor > rottenwheel, It will result in two different build, I don't like incactive code in the image. Could even be happen to go to 3 version (but not sure, need some time to think and thinkering about and analyze different threat models - and best would be to get some actual user input, why they want to have certain version)

< r​ottenwheel:kernal.eu > Beyond my bias, sounds stupid, for lack of a better word, to add more components, as that would effectively bar current SeedSigner users and owners from trying XMRSigner in the first place...

< r​ottenwheel:kernal.eu > Don't break the stateless concept. What the other two individuals claim to be a UX hurdle, is the main selling point of the SeedSigner project.

< r​ottenwheel:kernal.eu > I find it hard to understand how instead of looking at it from the security perspective, they latch on the UI/UX inconvenience...

< r​ottenwheel:kernal.eu > Cool, yeah, all WIP. I've said my piece. Congrats on getting fully funded, sir. 😊

< vthor > No, the stateless version will be always 100% staeless, not even microSD storing. And a version with microSD storing, need to see... And discous with actual user.

< vthor > rottenwheel, thank you very much! Hopen to see you in CDMX, but missed you.

< vthor > Need to walk the white monster before he pees on my feets. afk.

< plowsof > Meeting time #1113

< plowsof > greetings!

< o​frnxmr:monero.social > howdy

< plowsof > whats been going on since the last meeting? Monerotpia happened https://monerotopia.com/

< 0​xfffc:monero.social > Hello everyone

< plowsof > MKC3 call for workshops/presentations up https://x.com/MoneroKon/status/1860321346380533986 - ajs

< plowsof > 0xfff made a PR making some improvements to --no-initial-sync and wallet-rpc?

< plowsof > kewbit teased a CCS update for the haveno-gui... the monero -serai/wallet ccs proposal from kayabanerve has been merged https://ccs.getmonero.org/funding-required/

< o​frnxmr:monero.social > Make wallet-rpc great for the first time since bytecoin

< msvb-lab > Hello.

< plowsof > in my recent ccs update, i tallied up the funds we've repurposed or donated to the general fund from abandonned ccs proposals. 384.06 repurposed. 161.85 returned to the general fund https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/503#note_27312

< vthor > Hi!

< 0​xfffc:monero.social > monero-project/monero#9579

< o​frnxmr:monero.social > Boooo 👎

< plowsof > i look forward to testing this 0xfffc thank you

< o​frnxmr:monero.social > We should instead repurpose the old gemeralfund btc and xmr addresses funds from black hole to transparency report

< 0​xfffc:monero.social > ( You’re welcome. My pleasure. )

< ofrnxmr > monero-project/monero#9579 one of @0xFFFC's fixes

< plowsof > thanks

< plowsof > XMRSigner from vthor originating from repurposed funds :) but now his own work has been funded (was discussed today here)

< plowsof > ofrnxmr did you mention wallet-rpc using insane bandwidth amounts if left running 24/7?

< plowsof > ive never ran it at home so wouldn't notice

< 0​xfffc:monero.social > I believe this should alleviate the problem: monero-project/monero#9574

< plowsof > News: Monero Observer - Revuo Monero

< plowsof > oh, another PR

< o​frnxmr:monero.social > Yes

< plowsof > Siren/Stnby of digilol/moneropay are probably effected , as well as alot of merchants/swappers then

< o​frnxmr:monero.social > Like gb's per hr if a service utilizes close_wallet inbeteren open_wallet calls

< plowsof > good catch

< 0​xfffc:monero.social > Yes. It was basically days (or even months of? of computation wasted overall.

< o​frnxmr:monero.social > leads to very very much increased time to respond the longer the service is running

< o​frnxmr:monero.social > Resyncs the same blocks over and over.. and over again

< vthor > 0xfffc: but this will only avoid long opening time on open a wallet, would it be easy to quick fix the also the restore wallet from seed? (I suspect the long time on weak hardware comes from generating addresses on restore)

< plowsof > perhaps this is when i need to kill the process by grabbing its pid

< o​frnxmr:monero.social > I think there still may be an off-by-1 issue, as it syncs 2 blocks everytime it receives 1 more now

< 0​xfffc:monero.social > Great catch. I will try to fix it. Will dm you about it. 🙏🏻

< s​tnby:kernal.eu > Huh?

< plowsof > "if a service utilizes close_wallet inbeteren open_wallet calls" - ofrnxmr above. if moneropay does this then could be suffering from delays/bandwidth usage

< o​frnxmr:monero.social > tldr: these wallet-rpc issues should help projects, like moneropay, to function better

< o​frnxmr:monero.social > It also doesnt seem to refresh at open like its supposed to. Takes 20secs

< s​iren:kernal.eu > Yeah the resync thing is very annoying

< plowsof > nice

< plowsof > anything else to bring up? else we can move on to the ccs ideas

< plowsof > articmine shared thoughts on FCMP in MRL today which raised further discussion https://libera.monerologs.net/monero-research-lab/20241123

< plowsof > specifically the "post on FCMP++ costs and transaction sizes"

< plowsof > MRL can weigh in on this further.. now then

< plowsof > moving on, ccs ideas:

< plowsof > a. Carrot animated video

< plowsof > close/merge?

< plowsof > not enough positive engagement around this, looks like it will be closed

< dEBRUYNE > plowsof: As a side note, was the FCMP++ video officially released, or not yet?

< o​frnxmr:monero.social > I think this is a close, no engagement from proposer

< plowsof > vostoemissio released a video , yes, thanks

< o​frnxmr:monero.social > Not yet, xenu and vost redoing some of the script

< o​frnxmr:monero.social > The video they released was a pre-release, and kaya commented some inaccuracies

< o​frnxmr:monero.social > So theyre going to fix up and rerelease

< plowsof > thanks debruyne, here is vostos comment, open for feedback as above https://libera.monerologs.net/monero-community/20241121#c462513

< plowsof > closing Carrot animated video

< plowsof > b. CryptoCheckout WordPress plugin (for WooCommerce) & Shopify app

< plowsof > close/merge?

< o​frnxmr:monero.social > Close

< o​frnxmr:monero.social > Oh, for community news

< o​frnxmr:monero.social > Haveno Development and #haveno:development are the new homes for haveno dev on matrix and irc

< plowsof > a close from me. also special thanks for mrnaif from bitcart.io for sharing his insight regarding getting on to the shopify app store and such

< plowsof > the proposer of the above didnt even know how it was done and dropped the premise immediately

< plowsof > closing cryptocheckout

< plowsof > c. Monerotopia 2024 Marketing and Publicity

< plowsof > this was pre-approved, pending the upcoming update from geonic , we can move on unless that is on hand

< plowsof > at hand*

< o​frnxmr:monero.social > +1 plowsof

< dEBRUYNE > plowsof: ty

< o​frnxmr:monero.social > Seems the event went well though. Congrats

< plowsof > 👏

< plowsof > d. Gingeropolous 1TB MRC upgrade

< o​frnxmr:monero.social > Mrl i think liked this, but i again have mt reservations about continuously trusting folks who are irresponsible with our security and privacy

< o​frnxmr:monero.social > I think someone else should run the mrl lab pcs

< plowsof > 20 xmr, ram for MRL who expressed a need for it , and with positive updoots

< o​frnxmr:monero.social > Ginger refused to share the ips that he was forwarding to, and it took community whitehats to pry the info from internet logging or nslookup

< o​frnxmr:monero.social > And he deleted ips and still refused to share

< r​ucknium:monero.social > Maybe gingeropolous can do a sysadmin security short course :)

< r​ucknium:monero.social > I wouldn't mind doing one myself

< o​frnxmr:monero.social > Dodges any questions about the subject

< o​frnxmr:monero.social > i dont think it eas irresponsible due to being uneducated, but simply due to negligence

< o​frnxmr:monero.social > then tried to cover it up

< o​frnxmr:monero.social > And still pretends like nothing happened

< h​into:monero.social > hello

< l​ordx3nu:matrix.org > Re fcmp video: revisions made just waiting for Luke

< l​ordx3nu:matrix.org > Re carrot: vosto and I have expressed interest for doing an animated vid for this though not sure if there is enough interest

< plowsof > Rucknium is one of the main consumers of ram, if i could click my heels then Rucknium would be setting the hardware up in house for other MRL members

< l​ordx3nu:matrix.org > Waiting for Luke to sign off*

< plowsof > blame kayabanerve for any issues moving forward, noted

< l​ordx3nu:matrix.org > Thanks

< plowsof > thanks for sharing the update Xenu 💪

< l​ordx3nu:matrix.org > 😁

< r​ucknium:monero.social > Most of the expense of the MRC hardware was covered by gingeropolous. The implicit deal, I think, is that ging provides most of the hardware free-of-charge since he's mining Monero on it when the CPU threads are free. I hope that ging gives a fuller explanation for what happened with node.moneroworld.com , but consider that getting greenfield owned or rented hardware would be expe

< r​ucknium:monero.social > nsive for the CCS.

< r​ucknium:monero.social > Even with this proposal, ging is paying for the machine. The CCS is just for the RAM (which isn't really needed for mining)

< o​frnxmr:monero.social > Yeah, lets just keep funding his mining operation. I think that's messed up

< plowsof > merging gingeropolous - we could fund sech1 to purchase expensive monero mining equipment and let MRL use it upon request too

< o​frnxmr:monero.social > Didnt we pay for the rigs with prior ccs' too? I might be mistaken here

< r​ucknium:monero.social > No, he doesn't need this RAM for mining

< plowsof > ah ok

< o​frnxmr:monero.social > Why not just let ruck buy the ram for himself

< r​ucknium:monero.social > With a prior CCS, large SSDs were purchased. Again, that's what research needs, not mining

< nioCat > we are not funding his mining operation, his mining operation is being used by MRL

< r​ucknium:monero.social > nioCat has it right

< o​frnxmr:monero.social > thank niocat

< plowsof > thanks mbull

< plowsof > moving on

< h​into:monero.social > Rucknium: curious, what is the setup for storing the DB in ram?

< o​frnxmr:monero.social > thanks mbll

< r​ucknium:monero.social > In an R data.table

< r​ucknium:monero.social > You want the columns?

< h​into:monero.social > are those stored/reusable by other programs?

< r​ucknium:monero.social > Basically no. It's for statistical analysis. You cannot run the blockchain from this, if that's what you are asking.

< plowsof > e. v1docq47 - monerotopia 2024 voiceovers and working on xmr.ru

< plowsof > i've shared this proposal in the xmr.ru matrix room, continued positive support that gets him merged is coming in

< o​frnxmr:monero.social > Voting merge on account of successful history and always getting funding

< r​ucknium:monero.social > An R data.table is extremely fast for statistical analysis, especially for data that has a hierarchical structure like Monero: block -> tx -> ring -> ring member

< r​ucknium:monero.social > https://h2oai.github.io/db-benchmark/

< r​ucknium:monero.social > The downside is that it keeps the data in RAM, so if you have lots of data, you need lots of RAM.

< plowsof > looks like v1docq47 will be merged shuld the trend in feedback continue after its sat for a bit longer

< plowsof > Any other business?

< plowsof > Are we all waiting for a general fund transparency report?

< o​frnxmr:monero.social > Generalfund 0 1 2 3 4 and 5

< h​into:monero.social > does each program that needs data.table map LMDB data to a data.table on startup before continuing?

< plowsof > we can end the meeting here then. thank you all for attending

Automated by this