10:59:39 <***> Buffer Playback...
10:59:39 <carrington[m]> [07:45:58] Avoiding DDOS at $200 /XMR is more important than avoiding 30c fees at a theoretical 30k per XMR
10:59:39 <sech1> [07:46:16] there's no ddos
10:59:39 <mcfranko[m]> [07:46:33] That's not consensus level stuff if it's just for mempool level transactions
10:59:39 <jtgrassie> [07:47:13] the discussion is not about DDOS protection, it's spam (flood)
10:59:39 <jtgrassie> [07:47:32] right now it's cheap to flood
10:59:39 <mcfranko[m]> [07:47:37] People kinda use ddos and spam interchangebly
10:59:39 <sech1> [07:47:46] mcfranko https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L3719
10:59:39 <sech1> [07:48:35] yes, it's mempool only
10:59:39 <sech1> [07:48:52] but the fact is, you can't send transactions with lower fee
10:59:39 <mcfranko[m]> [07:48:53] Right, so that doesn't affect consensus
10:59:39 <sech1> [07:48:57] you have to mine them yourself
10:59:39 <mcfranko[m]> [07:49:11] I'm sure that if XMR becomes 30k, they can just change that part of the code
10:59:39 <sech1> [07:49:22] it's kind of consensus when all nodes run the same code. If you change it, half of the nodes will still use old rules
10:59:39 <mcfranko[m]> [07:49:41] Consensus only applies to the blockchain
10:59:39 <mcfranko[m]> [07:49:42] The mempool isn'
10:59:39 <sech1> [07:49:43] which will degrade UX when user connects to old node
10:59:39 <mcfranko[m]> [07:49:45]  * The mempool isn't part of consensus
10:59:39 <sech1> [07:49:59] so de facto changing it will require hardfork to make all nodes update
10:59:39 <mcfranko[m]> [07:50:03] Well I think pressing a button to switch to a new node is better than paying 30 cent fees
10:59:39 <mcfranko[m]> [07:50:10] No it wouldn't require hard fork
10:59:39 <sech1> [07:50:24] you don't understand
10:59:39 <sech1> [07:50:27] I know it's not consensus
10:59:39 <mcfranko[m]> [07:50:28] All nodes can still follow the same chain
10:59:39 <mcfranko[m]> [07:50:28] Some will just have different mempools than others
10:59:39 <sech1> [07:50:36] imagine you have your node right now with much lower fee limit
10:59:39 <sech1> [07:50:53] it won't be able to propagate your tx to other nodes, they will reject it
10:59:39 <sech1> [07:50:57] and it won't be mined
10:59:39 <carrington[m]> [07:51:06] Yes I was using flood and DDOS interchangeably. In this case the "service" is privacy.
10:59:39 <mcfranko[m]> [07:51:10] Okay, well presumably most of the other nodes will update
10:59:39 <mcfranko[m]> [07:51:18] And miners have an incentive to update their software
10:59:39 <sech1> [07:51:19] I'm talking about real implications of changing such stuff without hardfork
10:59:39 <mcfranko[m]> [07:51:35] Because otherwise they're missing out on tx fees
10:59:39 <sech1> [07:51:36] miners will have incentive not to update
10:59:39 <sech1> [07:51:43] so they'll only accept higher fee transactions
10:59:39 <sech1> [07:51:46] understand now?
10:59:39 <mcfranko[m]> [07:52:36] They're missing out on tx fees from the other transactions though, not updating would only help miners if they all colluded
10:59:39 <jtgrassie> [07:54:02] no, they will get both low and high fee txs by not updating
10:59:39 <jtgrassie> [07:54:25] if they update, they'll reject low fee txs
10:59:39 <jtgrassie> [07:54:59] hence sech1 is spot on
10:59:39 <mcfranko[m]> [07:55:15] I'm talking about updating to lower the minimum fee for the mempool in the 30k XMR scenario
10:59:39 <jtgrassie> [07:56:32] fees are not calculated based on fiat exch rate
10:59:39 <mcfranko[m]> [07:56:38] I know
10:59:39 <jtgrassie> [07:57:01] that's what you seem to be suggesting
10:59:39 <mcfranko[m]> [07:57:10] He was talking about the minimum fee would be 27 cents at 30k xmr
10:59:39 <mcfranko[m]> [07:57:24] I was saying that if we got to that point the minimum fee could just be lowered
10:59:39 <sech1> [07:57:58] it will most likely be lowered anyway due to higher usage
10:59:39 <jtgrassie> [07:58:36] that's the design yes
10:59:39 <msvb-lab> [09:27:55] Any chance to undelete my announcement on Reddit? I'm not directly typing nicknames because some have complained getting woken up in the night to correct Reddit mistakes and flaws.
10:59:39 <msvb-lab> [09:28:03] https://www.reddit.com/r/Monero/comments/oq2ufw/sixteenth_village_at_dc29_staff_meeting/
10:59:39 <NicholasvonKlitz> [09:34:53] What do people think of this? https://firo.org/guide/privacy-technology-comparison.html
10:59:39 <***> Playback Complete.
14:39:50 <Rucknium[m]> Raise minimum fees above a few cents via a software fix and you lock billions of people out of using XMR as a medium of exchange. Think very carefully about whether you want to do that.
14:58:17 <john_r365> @rucknium[m] - Currently the fees are on the order of a fraction of cent. That's the problem that needs fixing (for cheap spam avoidance). That shouldn't lead to transactions costing >5 cents - I wouldn't have thought
14:58:41 <john_r365> Asked previously, but does anyone know where to find a proposal that looks at increasing fees?
15:04:28 <msvb-lab> Reminder that we have a village staff meeting in about three hours, happening on Saturday 24 July at 18:00 UTC on #monero-events.
15:07:07 <Rucknium[m]> I hope it wouldn't. Recall that Dogecoin set the minimum tx relay fee at 1 DOGE a few years ago to guard against spam. At the time they were probably thinking "This will never get above 1 cent, let alone 50 cents." Now they have a mess of technical debt to unwind and a "tipping cryptocurrency" that cannot really be used for tipping.
15:35:50 <Rucknium[m]> For an extensive overview of the Dogecoin minimum fee issues, see https://github.com/dogecoin/dogecoin/discussions/2347 . Patrick Lodder is a Dogecoin core dev.
15:37:54 <john_r365> @Rucknium[m] - I can think of worse problems than Monero jumping to a $25B marketcap - but yes, I understand your point
16:02:45 <xmrscott[m]> nioc: Space logs can now be found here: https://forum.monero.space/d/93-monero-space-meeting-saturday-17-july-2021-at-17-utc-minutes
16:26:37 <Keiji[m]> Community meeting in 35 minutes!
16:35:40 <nioc> xmrscott[m]: ty :)
17:00:52 <Keiji[m]> Let's begin the Community Workgroup Meeting now!
17:01:04 <Keiji[m]> - Greetings
17:01:21 <v1docq47> hi
17:01:36 <ErCiccione> Hi
17:03:01 <Keiji[m]> - Community highlights
17:03:34 <Keiji[m]> Outside of workgroups, anything people want to highlight?
17:05:07 <Keiji[m]> - CCS updates
17:05:52 <Keiji[m]> I don't see any new CCS in Ideas or Funding Required since July 10 meeting, but are there any people wish to discuss?
17:06:41 <ErCiccione> quiet today :)
17:06:56 <v1docq47> too quiet :)
17:07:01 <Keiji[m]> Haha yep. It happens I guess
17:07:40 <mj-xmr[m]> I'd like to know if there are any special requests for my CSS, like where I should concentrate my mental energy, because there are many fronts to work on.
17:07:40 <mj-xmr[m]> I'm currently building a local matrix of extreme configurations, that would be too resource hungry for the GitHub CI to handle.
17:08:07 <mj-xmr[m]> The GitHub action issues are mostly taken care of.
17:08:55 <mj-xmr[m]> The result of the build matrix will be published just as the other report, of course.
17:09:34 <john_r365> mj-xmr - it might be difficult to get a good reply to that in this meeting (could be wrong) - but perhaps if you wrote up a short post somewhere of the things you think are important to be working on, community members could give some feedback on which they think deserve priority?
17:10:12 <ErCiccione> yeah that would be useful. Even just an issue or something like that.
17:10:34 <Keiji[m]> GitHub Issue w/ link on Reddit maybe?
17:11:01 <mj-xmr[m]> OK, got it.
17:12:22 <Keiji[m]> Personally, I'd say if there's developers who mentioned issues w/ patch integrations, that first, followed by user issues ?
17:13:59 <Keiji[m]> - Workgroup reports
17:14:19 <Keiji[m]> I think we have just Website and Localization here?
17:14:40 <Keiji[m]> So we can start with b. Localization workgroup
17:15:20 <ErCiccione> not much to say. Today i updated the strings of the GUI and the CLI, so people can translate the new stuff.
17:16:05 <ErCiccione> people are actually translating every day, so soon i'll probably PR the updated strings upstream soon
17:16:41 <Keiji[m]> Nice! Great to hear!
17:17:38 <Keiji[m]> f. Website workgroup
17:19:19 <john_r365> side note ErCiccione - is there any tracking on how much the various languages are used? i'd guess not due to privacy, but just curious if there's any way at all?
17:19:45 <john_r365> perhaps node concentration by country is the closest proxy
17:20:17 <ErCiccione> for the getmonero, there should be. We have a matomo instance for analytics but has been broken since the very beginning. With that we can get some basic analytics from the server logs.
17:20:30 <coinstudent2048[> <ErCiccione "not much to say. Today i updated"> Is there a website for translation, or just github? I am just waiting someone started my language already :3
17:20:53 <ErCiccione> I've been wanting to access those info for quite some time for that very reason. With statistics we can work with lanaguages better and make informed choices/changes
17:21:07 <ErCiccione> coinstudent2048: https://translate.getmonero.org
17:21:24 <john_r365> from memory, running matamo shouldn't be very complex. any idea why it's not working/broken?
17:22:02 <john_r365> "
17:22:24 <ErCiccione> no. I've been talking with pigeons about it a few times but nothing really came up yet
17:22:25 <john_r365> "statistics we can work with lanaguages better and make informed choices/changes" -> exactly why i asked, would help with energy prioritisation
17:22:49 <ErCiccione> we have been working on language autodetection as well, so that was prioritized
17:26:09 <john_r365> next topic Keiji[m]?
17:26:40 <Keiji[m]> - Open ideas time
17:26:40 <Keiji[m]> Anything people want to discuss that wasn't talked about earlier?
17:28:27 <john_r365> I won't bring up transaction fees again *laugh face* as I've brought it up enough recently. but that's the main thing that's bugging me. seems far too cheap to store data on monero, that nodes be downloading and verifying for years to come
17:28:45 <john_r365> *will be
17:29:39 <ErCiccione> i think a github issue is the best place with that. There are many factors to consider
17:30:05 <Keiji[m]> Ok. I think Artic Mine is the resident transaction fee expert and they aren't here. Also, yes, probably GitHub is best for long discussion
17:30:17 <john_r365> agreed
17:30:22 <msvb-lab> ArticMine is here I think?
17:30:36 <msvb-lab> At least a few minutes ago.
17:32:00 <Keiji[m]> I guess just post a link here in IRC when you create the issue and ping Artic Mine then?
17:32:27 <Keiji[m]> If no one else has anything to discuss, we can conclude the meeting. Next meeting in 2 weeks?
17:32:55 <wfaressuissia[m]> What's the main purpose of such meetings ?
17:33:28 <jberman[m]> I have 1 thing
17:33:36 <jberman[m]> Yesterday it was mentioned in #monero-dev people wanted to discuss the divide by 0 bug and the patch for that in next release. I can share a status here and my opinion on a way forward. But considering above, I think the PR on github is the best format for that discussion, it's also fairly long with a number of factors to consider
17:33:36 <Keiji[m]> Mainly to pass down things, ask for help (like CCS feedback when we have more people)
17:34:50 <Keiji[m]> If you want to share the short summary here as not everyone follows the Issue probably that would be fine I think
17:35:01 <msvb-lab> Don't forget that we have a village staff meeting (for Defcon 5-7 August) in a half hour on #monero-events.
17:35:54 <jberman[m]> The PR (https://github.com/monero-project/monero/pull/7798) has 2 parts to it. First, it changes the decoy selection algorithm to correctly select more recent decoys in a ring. Second, it prevents a divide by 0 bug.
17:35:54 <jberman[m]> In IRC and in that issue, sech1 and tobtoht raised valid concerns that a change to the decoy selection algo would break tx uniformity. The ensuing discussion has been related to that
17:36:36 <jberman[m]> I believe there are 2 options of handling this concern:
17:36:36 <jberman[m]> 1. I shared a fix that would prevent the divide by 0 bug, and would only alter the decoy selection algorithm for clients that would be affected by divide by 0.
17:36:36 <jberman[m]> 2. Being 100% certain the fix does not pose material risk to users through breaking tx uniformity, and going with the fix in the PR.
17:36:58 <jberman[m]> On #2, I believe I've provided a fairly strong case why the risk posed to users seems likely immaterial, and more eyes on that would be appreciated.
17:36:58 <jberman[m]> Perhaps the best course of action is going with option #1 for now while we work toward 100% certainty for option #2. I can continue with a deeper analysis with more mathematical rigor in the meantime.
17:37:00 <ErCiccione> i think we'll need a dev meeting soon, there are a lot of things to discuss
17:37:49 <jberman[m]> Ya this seems like a difficult thing to discuss in this format
17:38:15 <Keiji[m]> Usually dev meeting happens tomorrow, right?
17:38:29 <ErCiccione> it is, that's why it's good to talk about it as much as possible in the issues, so to not repeat long explanations here
17:38:55 <ErCiccione> they were usually on sunday iirc, yeah
17:39:02 <Keiji[m]> Good point. Thanks for the summary jberman!
17:39:35 <Keiji[m]> Maybe someone should ask to have a meeting tomorrow on GItHub and then mention on reddit as well
17:40:02 <ErCiccione> tomorrow is too soon. Maybe next sunday
17:40:22 <ErCiccione> i know sarang might have some research to share as well, so the meeting could be a good place for doing that
17:40:56 <wfaressuissia[m]> -dev and -lab meetings were independent previously, no ?
17:41:02 <Keiji[m]> Whatever people believe is best, depending on how time sensitive getting PRs is in
17:41:19 <Keiji[m]> Whatever people believe is best, depending on how time sensitive getting PRs in is
17:41:57 <ErCiccione> wfaressuissia: they still are afaik, but i don't think there are regular research meetings anymore
17:43:05 <tobtoht> hey, would like a dev meeting to discuss this as well. selsta mentioned the eta for the next release being in 2 weeks, 1 week ago, so if the meeting is planned for next week that may need to be delayed.
17:45:05 <jberman[m]> seems it would be easier to establish a meeting time directly on that PR/give time for people to see it
17:45:26 <jberman[m]> selsta can weigh in on release there
17:45:51 <Keiji[m]> Yes, I guess comment there and main stakeholders/developers can figure out best meeting time and stuff
17:46:20 <tobtoht> yep, feel free to propose a date/time on the github issue
17:46:46 <ErCiccione> meeting in two weeks is fine for me tobtoht 
17:47:38 <selsta> jberman[m]: luigi should be back monday, then we can do merges and prepare a release
17:47:58 <jberman[m]> ahh, got it ok
17:48:28 <Keiji[m]> Ok, any other things people want to discuss before we conclude the Community meeting?
17:50:48 <Keiji[m]> Sounds like no. Hope to see everyone in two weeks then! I'll post the logs soon to GitHub
17:50:55 <Keiji[m]> Thanks for everyone who could make it
17:51:22 <mj-xmr[m]> Thanks for moderating :)
17:51:26 <Keiji[m]> I think for next meeting better advertising it on Reddit might help remind more people this meeting exists again
17:51:27 <msvb-lab> Thanks for the good meeting Keiji[m].
17:52:17 <msvb-lab> Reddit is broken regarding advertising meetings, I tried that several times this week for the village staff meeting (in ten minutes.) All the reddit messages get deleted automatically.
17:53:52 <Keiji[m]> I think it's modded heavily due to spam. Probably messaging the mods right after posting would help
17:54:04 <Keiji[m]> Reddit has a message mods feature
18:00:11 <msvb-lab> Yes Keiji[m] I did exactly what you suggested, which led to the complete failure of Reddit (which deleted a message that was nothing similar to spam.)
18:00:42 <msvb-lab> It seems to be generally a failure, as this problem has been happening for many months with nobody trying to solve it (or succeeding at it.)
18:44:31 <ArticMine> <john_r365> I won't bring up transaction fees again *laugh face* as I've brought it up enough recently. but that's the main thing that's bugging me. seems far too cheap to store data on monero, that nodes be downloading and verifying for years to come <---- https://github.com/monero-project/research-lab/issues/70
18:45:00 <ArticMine> As part of this issue the low fee will rise ~5x
18:45:30 <ArticMine> This is for the next fork
18:52:06 <ArticMine> More importantly the minimum fee will allow for scaling of the blocksize
18:52:18 <ArticMine> This is not the case now
19:00:15 <msvb-lab> Oh, there may be a question about official Defcon entrance badges.
19:00:25 <msvb-lab> Oops, qwrong channel.
19:31:31 <john_r365[m]> Thanks ArticMine - great work on that. 
19:31:32 <john_r365[m]> What is the current status of issue 70 in relation to implementation?
19:31:32 <john_r365[m]> Is the code tested ready for deployment, and just awaiting the next hard fork? Or something else. 
19:31:32 <john_r365[m]> Thanks! 
20:38:04 <xmrscott[m]> <msvb-lab "It seems to be generally a failu"> I had no issues when I posted for a meeting a week ago. Can do so for next meeting