Monero Community Workgroup Meeting: Saturday 16th March 15:00UTC

Logs

< plowsof:matrix.org > Greetings https://github.com/monero-project/meta/issues/979

< diego:cypherstack.com > Please do. Would be thrilled.

< plowsof:matrix.org > may i ask Diego Salazar if the cypherstack bp++ 1st payment is being handled/handled?

< diego:cypherstack.com > Yes it was. Thanks.

< plowsof:matrix.org > thanks for confirming and success further!

< rucknium:monero.social > Hi

< plowsof:matrix.org > i suppose the biggest highlight of the prev 2 weeks has been the transaction spam* and the resulting discussions (ongoing)

< plowsof:matrix.org > Recent bump in block sizes https://bitinfocharts.com/comparison/monero-size.html#3m Automatic fee has been fixed to go between normal/low depending on mempool status. there is also a new PR to allow miners to limit block weights here from sech1, suggested by Rucknium

< plowsof:matrix.org > hi Rucknium, did you mention having second thoughts about the idea? or?

< michael:monero.social > Hello.

< r4v3r23:monero.social > yo

< plowsof:matrix.org > hi

< rucknium:monero.social > Miners self-limiting the size of blocks they produce? No second thoughts about adding the parameter to get_block_template. We don't know yet if it is a good idea to suggest that miners actually set the param lower.

< plowsof:matrix.org > ah thanks for clarifying

< plowsof:matrix.org > its a shame the -events cfp has ended, maybe some talks reg the recent transaction spam could be submitted (if not already ajs_?)

< nioCat > it's a soft deadline

< plowsof:matrix.org > hello, we have a cat working for us now. she updates the copyright dates every year copyCat

< nioCat > articmine has submitted a talk about changes to the dynamic block protocol

< nioCat > now back to laundry

< plowsof:matrix.org > awesome, thanks!

< rucknium:monero.social > IIRC, you are only supposed to update the copyright year on files that have actually been edited in that year.

< nioCat > *including fees

< plowsof:matrix.org > https://featherwallet.org/changelog/ tobtoht has been pushing out new versions 👍️ selsta says we are waiting for bF's availability to release 18.3.3 (thank you to the Gitian builders/signers!) https://github.com/monero-project/gitian.sigs

< plowsof:matrix.org > seems sane Rucknium reg copyright changes, im not even sure updating that date even means anything but the core repo gets several pull requests a year of people updating them

< plowsof:matrix.org > there was even an open invitation for contributors to update it posted on reddit

_< ajs:matrix.org >__ CFP deadline ended yesterday, but we might still accept additional talks depending on space availability

< plowsof:matrix.org > https://www.reddit.com/r/Monero/comments/1bellkj/update_github_dates_to_2024/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

< plowsof:matrix.org > events team has ALOT of updates regarding sponsor payments and other misc things. TheFuzzStone has been offering advice on how to get fiat / cash invoices paid for monerokon (while a bank account is in the workings) - one advice though, please confirm the minimum amounts with TheFuzzStone and do not under any circumstances joke about them !

< plowsof:matrix.org > - https://github.com/monero-project/monero-docs

< plowsof:matrix.org > sgp has set up getmonero.dev , which is a fork of https://github.com/monerodocs/md

< plowsof:matrix.org > dan shared that the underlying tech is mkdocs @ https://github.com/mkdocs/mkdocs

< plowsof:matrix.org > does anyone have any input on this?

< rucknium:monero.social > We need to figure out domain ownership dead man switches. If they are possible somehow.

< mrcyjanek0:matrix.org > Very good idea, some technical introduction regarding how to build things that use monero's codebase would be good (I'm willing to contribute that), because it is quite easy to become lost when trying to use the codebase for first time.

< mrcyjanek0:matrix.org > So not only cli/rpc/gui docs but also wallet2_api.h and possibly libraries for other languages (rpc clients, and ffi).

< plowsof:matrix.org > i was asked by at least one person why the license is changed for the unofficial version at getmonero.dev to "Copyright © MoneroDocs.org Contributors, MAGIC Grants, and Other Contributors. MIT Licensed."

< plowsof:matrix.org > this was done before 'monero - docs ' on a monero-project repo was considered possible

< plowsof:matrix.org > sgp has explained the reasons but theyre not at hand atm

< rucknium:monero.social > AFAIK, if MAGIC Grants added any content, then you are supposed to add them to the copyright statement. The MAGIC Monero Fund committee (I know it's confusing) has not helped with getmonero.dev yet by the way.

< plowsof:matrix.org > they are named specifically while "Contributors" are not

< plowsof:matrix.org > although on github the full list of contributors is visible

< rucknium:monero.social > For example, https://monerofund.org/ has "© Open Sats Initiative and MAGIC Grants, 2024". The website code was forked from Open Sats. Then we changed the code a lot to fit our requirements.

< rucknium:monero.social > Ok. Someone can make a PR to add the full list to the website footer.

< plowsof:matrix.org > then we would have people complaining about the infinitely long list of contributors and how we need a javascript search function

< rucknium:monero.social > For a permissionless currency, it seems you need the permission from a lot of people to set up anything in the Monero ecosystem.

< plowsof:matrix.org > a deadmans switch for domain ownership 🤔 interesting.. i could imagine a few "im not dead, the reminder when to my spam box, can you transfer it back lol"

< plowsof:matrix.org > anything else to discuss before getting to the ccs idea list?

< plowsof:matrix.org > quick plug of a bounty for adding ipv6 to monerujo , requested by shortwavesurfer2009 https://bounties.monero.social/posts/102/1-700m-monerujo-add-full-ipv6-support

< plowsof:matrix.org > SNeedleWoods add LegacyEnoteOriginContext for Seraphis pull request 🫡

< plowsof:matrix.org > ok lets discuss the idea list

< plowsof:matrix.org > 5. CCS updates | hinto | tobtoht

< plowsof:matrix.org > a. Unnamed Monero Wallet development

< plowsof:matrix.org > aka xmruw

< plowsof:matrix.org > Czarek Nakamoto: is here, and has provided a comment comparing his work to valdracs monero-wallet-sdk

< plowsof:matrix.org > https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/437#note_23529

< mrcyjanek0:matrix.org > Correct, it is quite long and technical but it comes down to the fact that both project have different goals and target different usecases.

< mrcyjanek0:matrix.org > > monero-wallet-sdk focuses on android while xmruw focuses on being cross platform

< mrcyjanek0:matrix.org > > monero-wallet-sdk focuses on stable api for developers while xmruw focuses on offering as small abstraction as possible

< mrcyjanek0:matrix.org > > both projects aim for good developer experience (things like IDE suggestions)

< plowsof:matrix.org > r4v3r23 has suggested separating monero_c from xmruw

< plowsof:matrix.org > the proposal has 2 milestones, is that everything listed under 'plans'?

< mrcyjanek0:matrix.org > I assume that he meant separating them into 2 CCSes. I'm slightly against this idea because it would make development more annoying and testing rather impossible, the projects monero_c, byteworks, offline_market_data, monero.dart are all separate and can be used easily by 3rd party software.

< mrcyjanek0:matrix.org > Yes, it is everything listed in plans + some other minor features, such as PoS mode for sellers (which is currently in works), it will allow people to input product IDs and scan them to create real-life PoS experience

< r4v3r23:monero.social > no, i meant removing the xmruw portion. besides feather (already establshed dev/wallet) all other wallets get funding on their own

< mrcyjanek0:matrix.org > and the docs update I've mentioned earlier - as I think that I've hit every possible edge case I could while working with monero code.

< plowsof:matrix.org > the question is what is the sentiment here, we had comments from tobtoht (who is having a rest after release) and rbrunner. just waiting for a response

< mrcyjanek0:matrix.org > > all other wallets get funding on their own

< mrcyjanek0:matrix.org > monero-wallet-sdk did their demo wallet as a part of CCS.

< mrcyjanek0:matrix.org > you can consider xmruw the same, as it is really "just a demo" of all the libraries mentioned above.

< plowsof:matrix.org > that came about because molly required it be created for various reasons (some security related)

< r4v3r23:monero.social > demo wallet is just that, a demo wallet. your asking for funding for the whole wallet project. its in the title of the ccs

< r4v3r23:monero.social > i guess all wallets are "just demos" of wallet2

< plowsof:matrix.org > the ccs funded tesla to accept monero as payment and coral reef. anything is possible

< r4v3r23:monero.social > noted

< mrcyjanek0:matrix.org > Yes, I'm asking to support the full suite, all packages and a wallet. Developing libraries without a proper usecase for them just doesn't work. The wallet itself is not the major task here. monero_c is currently the biggest of them. monero_c wouldn't exist without xmruw, and xmruw can't exist without monero_c.

< plowsof:matrix.org > lol

< mrcyjanek0:matrix.org > My current tests on byteworks pass 100%, but in real-world usecases I've noticed bugs. I can't separate the project without a large cost in terms of how good the software is.

< mrcyjanek0:matrix.org > My current tests on bytewords pass 100%, but in real-world usecases I've noticed bugs. I can't separate the project without a large cost in terms of how good the software is.

< plowsof:matrix.org > there was alot of interest in having monero inside molly, this was merged. from this ccs came the need for monero-wallet-sdk (monero_c)

< plowsof:matrix.org > xmruw needs monero_c

< r4v3r23:monero.social > monero_c doesnt need xmruw

< mrcyjanek0:matrix.org > Also xmruw targets platforms not officially supported by any wallets - such as SailfishOS and alpine linux (including PostmarketOS). So the entire effort also makes it easier to use monero in privacy enabled setups.

< rucknium:monero.social > plowsof: I don't recall seeing comments from rbrunner and tob about this CCS. Is it in the IRC/Matrix logs?

< plowsof:matrix.org > sorry moment

< plowsof:matrix.org > i clipped the logs of the prev meeting half way* will fix that later

< plowsof:matrix.org > tobtohts comment https://libera.monerologs.net/monero-community/20240302#c337258

< mrcyjanek0:matrix.org > > monero_c doesnt need xmruw

< mrcyjanek0:matrix.org > Making the library on its own will require me to write synthetic tests for all the libraries because I wouldn't be able to uncover bugs (such as the one in bytewords).

< mrcyjanek0:matrix.org > and tests are nowhere near the user testing in terms of how well they catch bugs.

< mrcyjanek0:matrix.org > and sure I can make demos for each project separately, but that would be just a waste of time, and wouldn't deliver any real project.

< mrcyjanek0:matrix.org > while now we have a cross platform wallet.

< r4v3r23:monero.social > also, a couple of devs asked why wallet2_api instead of wallet2.h directly

< r4v3r23:monero.social > mooo asked that when i firsted mentioned a C lib was being worked on

< r4v3r23:monero.social > tohtobt also expressed that, saying wallet2_api.h itself is an abstraction on top of wallet2.h

< plowsof:matrix.org > rbrunners comments must have came some days later (i will find them unless it was a false memory)

< plowsof:matrix.org > commenting on the perceived ease of adapting to seraphis

< mrcyjanek0:matrix.org > > tobtohts comment

< mrcyjanek0:matrix.org > line 63: OG response: https://pastebin.com/NQb5ejWc, I don't want to wait until wallet3 shows up, and I want to work on the project currently, when it comes I'll also do my best to enable people to have a seamless migration if they opted to use monero_c.

< plowsof:matrix.org > thanks Czarek i was looking for the paste

< mrcyjanek0:matrix.org > > also, a couple of devs asked why wallet2_api instead of wallet2.h directly

< mrcyjanek0:matrix.org > Because there is api, that tends to be more stable than internal functions in general, and it was used by every single lib/wallet I've seen (except for simplewallet).

< mrcyjanek0:matrix.org > > tohtobt also expressed that, saying wallet2_api.h itself is an abstraction on top of wallet2.h

< mrcyjanek0:matrix.org > True, a stable abstraction. I didn't feel the need to invent anything from scratch, I've just wrapped already existing code.

< plowsof:matrix.org > rbrunners comments a day later https://libera.monerologs.net/monero-community/20240303#c337362

< mrcyjanek0:matrix.org > also r4v3r23 you didn't appear to have anything against the way it is being developent, and you were pretty close to the project since day 0.

< r4v3r23:monero.social > tohtobt mentioned they managed to remove wallet2api and reduce to "libwalletqt -> wallet2.h in most places"

< plowsof:matrix.org > "no such brand-new Monero wallet should start today and thus "this late in the game" without the dev(s) having a good long look at Jamtis and Seraphis first, and then add info to their CCS proposal how their project looks in this light."

< plowsof:matrix.org > from rbrunner above^

< mrcyjanek0:matrix.org > sure, but that would cause reinvention of the wallet2_api.h in my usecase, which I didn't feel the need to do. There is a stable API available, so I've decided to use it.

< r4v3r23:monero.social > i was waiting for it to be stable before making judgement, and that was a major part of the delay

< r4v3r23:monero.social > this entire thing started from an experiment

< mrcyjanek0:matrix.org > I can't say anything else except "it happened". I agree that it shouldn't, but since most of the work is already done I think that polishing it is the way to go, to deliver a stable and cross platform wallet and libraries to power many new apps and projects.

< rucknium:monero.social > Do we have time to discuss my CCS idea? It's not posted yet, but I would like input on the first draft

< rucknium:monero.social > *for the first draft

< mrcyjanek0:matrix.org > at this point abandoning the project is not an option for me - too much time got put into it. However I need funding to continue working on it, otherwise it will cause huge delays as I'll have to work on other things first

< plowsof:matrix.org > yes, but b. Payout request for monero-gui flathub proposal comment

< plowsof:matrix.org > in the comment i have linked the stats showing flathub flatpak receiving updates throughout the year. the manifest is on the core repo but not complete. payout request for milestones 2 - 3 - 4 - 5

< plowsof:matrix.org > if anyone wants to read / vote / comment on that please do

< plowsof:matrix.org > Rucknium can you share your CCS idea(s)?

< rucknium:monero.social > This would be 20 hours/week for three months of statistical research to improve Monero's privacy, guide protocol decisions, and respond to Monero developer requests for statistical analysis of code changes where needed. The start would be to analyze the suspected black marble flooding that is happening now. Effects of possible countermeasures, minimal safe parameter levels, and pr

< rucknium:monero.social > oviding evidence for and/or against the black marble flooding hypothesis.

< plowsof:matrix.org > kinghat: is a monero gui flatpak enjoyer and could offer some feedback.. selsta has seen BMP work through flatpak issues also

< rucknium:monero.social > This would be in parallel to the OSPEAD work that is near completion. Basically, the flooding analysis is more urgent since it's happening now. OSPEAD probably has to wait for the next hard fork for safe implementation.

< rucknium:monero.social > Other research questions could be ring member binning, Pocket Change privacy, EAE/EABE attack, fee discretization, and 10 block lock adjustment safety.

< rucknium:monero.social > I could not research all those topics in a 3 month period of course, but the community can help set research priorities.

< plowsof:matrix.org > would this be a similar deliverable as "analysing a flood"?

< plowsof:matrix.org > the recent spam is definitely a hot topic. you even shared some figures reg possible ring size degradation

< rucknium:monero.social > OSPEAD will suggest an update to Monero's decoy selection algorithm for ring signatures to mimic the real spend age distribution.

< rucknium:monero.social > plowsof: The first priority is to research possible critical thresholds of flooding that would be a major threat to user privacy. See how bad it could be if it is actually black marble flooding.

< rucknium:monero.social > Then yes do more analysis like "Fingerprinting a Flood". I would re-run our 2021 analysis and also analyze the mempool tx arrival data that we didn't have back in 2021. And maybe try to crawl the network to figre out the possible node origin(s) of the flood.

< rucknium:monero.social > There is a risk ,if the effective ring size gets too low, of chain reaction attacks.

< plowsof:matrix.org > some of ruckniums previous contributions are detailed here https://rucknium.me/

< rucknium:monero.social > This was our analysis back in 2021 of a smaller suspected spam incident: https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60

< rucknium:monero.social > The effective ring size analysis and chain reaction threshold analysis would help decide, for example, if mining pools could help by voluntarily self-limiting their block size and/or how raising the ring size to certain levels could help. And any fee changes or dynamic block size changes.

< rucknium:monero.social > Any input appreciated :D

< nioCat > will you work with ArticMine on this?

< plowsof:matrix.org > positive effects if any of limiting block sizes ... how raising ring sizes could help... looking at fees and dynamic block sizes seems important to a layman like myself

< nioCat > or rather have input from him

< rucknium:monero.social > Yes, if ArticMine wants to.

< nioCat > him helping you direction would be great

< rucknium:monero.social > ArticMine and I already discussed some preliminary analysis and proposals in #monero-research-lab:monero.social

< nioCat > my vote is merge :D

< rucknium:monero.social > Ok I will directly ask him if he wants to work closely on this.

< plowsof:matrix.org > some of it is here https://libera.monerologs.net/monero-research-lab/20240314#c347465

< plowsof:matrix.org > irc users cant access the matrix logs is all

< ack-j:matrix.org > +1 for Ruck CCS

< rucknium:monero.social > I am working on a preliminary document that estimates empirical effective ring size if the tx volume is black marble flooding, long-term projections of effective ring size at several nominal ring size levels, and tx confirmation delay analysis.

< plowsof:matrix.org > +1 here

< plowsof:matrix.org > +2 if you tell me how i can get on a contributor list with the least mount of work

< rucknium:monero.social > And the additional GB added to the blockchain and total fee paid by the attacker if it is an attacker.

< plowsof:matrix.org > available for running scripts on server(s) as always

< rucknium:monero.social > Well, you already contributed the mempool data collection, so you get a mention :)

< ack-j:matrix.org > I’m in favor of having a proper security analysis of the newly proposed scaling definitions.

< ack-j:matrix.org > We should have a strong idea of cost to perform a DOS or black marble attack

< plowsof:matrix.org > also spackle_xmr, your churn script is gone from github, i was wondering about that

< plowsof:matrix.org > thanks for sharing the idea Rucknium and those who left feedback so far

< woodser:monero.social > yeah I'm also curious to see more analysis on cost to spam the blockchain

< woodser:monero.social > it's not helping us if it's too cheap

< rucknium:monero.social > I can add that. It was one of my items in "A Statistical Research Agenda for Monero" https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2023-Slides.pdf

< rucknium:monero.social > "Monero’s dynamic block size has not received the same amount of research scrutiny as its privacy features."

< 123bob123:matrix.org > “Organic” “usage”

< plowsof:matrix.org > pls do not forget that the "cost" in terms of xmr is HIGH (if xmr was priced around BTC) as sech1 stated we also 5*d the fees recently

< rucknium:monero.social > 1) Can the dynamic block size parameters result in undesirable outcomes, e.g. too fast or too slow block size increase?

< rucknium:monero.social > 2) The interaction of block size and fee policy is supposed to adjust fee to the purchasing power of a unit of XMR in the future (a type of “oracle” problem). Can this go wrong?

< rucknium:monero.social > 3) Is it possible to have a fee policy that discourages adversarial spam but provides low fees for people around the globe?

< rucknium:monero.social > ^ Those were some of my research agenda questions from Monerotopia 2023

< plowsof:matrix.org > i think we can put an end to the meeting and continue discussion on this. thank you all for attending and sorry for the slow start and going over

Automated by this

continued

16:31:39 <m-relay> <123bob123:matrix.org> Probably should just fork monerodocs and modify from there, then things would get started, otherwise we have to wait for core to setup. 
16:31:40 <m-relay> <123bob123:matrix.org> mkdocs material has client side search so if js is disable still works
16:31:40 <m-relay> <123bob123:matrix.org> https://squidfunk.github.io/mkdocs-material/setup/setting-up-site-search/
16:31:41 <m-relay> <123bob123:matrix.org> and also can be run offline
16:31:41 <m-relay> <123bob123:matrix.org> https://squidfunk.github.io/mkdocs-material/plugins/offline/?h=offline
16:33:39 <nioCat> plowsof: am I remembering correctly that the 5x fee increase was due to the reduction of tx size and therefore fees brought about by bulletproofs?
16:35:04 <m-relay> <plowsof:matrix.org> sech1^ im pretending to be afk because i dont know
16:35:46 <m-relay> <plowsof:matrix.org> thanks for the extra context/reasoning if true nioCat
16:36:01 <m-relay> <plowsof:matrix.org> thanks Dan 🤐 | alderman (Is not the man & Braxman Tomsparks Advocate )
16:37:36 <sech1> I don't remember
16:38:04 <nioCat> we went from MLSAG to CLSAG Oct 2020
16:38:34 <m-relay> <rucknium:monero.social> IIRC BulletProofs+ reduced tx sizes by about 10%. I am not sure, but I think the Fingerprinting a Flood analysis influenced the 5x fee increase .
16:38:35 <nioCat> I think fee change was after that 
16:39:29 <m-relay> <rucknium:monero.social> Fingerprinting a Flood estimated "At the time, the exchange rate for Monero was about 200 USD per XMR, so the cost of generating ~365,000 transactions would have been $1,000. A 2-in/2-out transaction weighs about 1.93 kB so these transactions would have added about 700 MB to the chain, at a cost of $1.40 per MB."
16:40:48 <nioCat> bulletproofs Oct 2018
16:44:25 <m-relay> <123bob123:matrix.org> https://github.com/monero-project/monero-docs. plowsof maybe luigi can enable discussion on repo?
16:44:26 <m-relay> <123bob123:matrix.org> https://docs.github.com/en/discussions/quickstart#enabling-github-discussions-on-your-repository
16:47:48 <m-relay> <123bob123:matrix.org> Dont want to have to make matrix room/irc for docs
16:53:05 <m-relay> <rucknium:monero.social> Some of the discussion about the 5x fee increase in the August 2022 hard fork happened here: https://github.com/monero-project/research-lab/issues/70
16:56:18 <plowsof> xmrack has one specifically for spam :P
16:57:29 <m-relay> <rucknium:monero.social> If we feel the need to hide how the dynamic block size works to prevent its misuse, that is not a good place to be in. Not a criticism of your decision, spackle.

monero-project / meta

Monero Community Workgroup Meeting: Saturday 16th March 15:00UTC #979