05:19:05 <selsta> .merge+ 8145
05:19:05 <xmr-pr> Added
10:28:00 <nifty2[m]> hello, my monero gui wont close, it is constantly checking local node status. I dont understand why?
10:29:15 <selsta> which OS? also did you close it while the wallet was still syncing?
10:31:01 <nifty2[m]> selsta: windows. possibly, what effect would would it have? can i just restart?
10:31:19 <selsta> also do you use Ledger?
10:31:44 <nifty2[m]> never heard of that, no
10:31:53 <selsta> ok, you can kill it with task manager
10:33:06 <nifty2[m]> ah, thanks. its been steaming my computer for 3 hours
15:01:18 <ErCiccione> Meeting here in ~2 hours: https://github.com/monero-project/meta/issues/652
15:01:27 <ErCiccione> s/652/655/
15:15:16 <Guest66> hi
17:00:34 <selsta> meeting time :)
17:00:35 <ErCiccione> It's meeting time!
17:00:39 <ErCiccione> Hello folks! This is an important meeting focused on the next network upgrade (hard fork). Code freeze supposed to be on January 15th, but the changes needed haven't been merged yet. During this meeting we'll explore the status of these PRs, so that after we can decided new dates.
17:00:54 <ErCiccione> After that, we will take a look at other features/changes waiting to be merged that would be cool to have in the next network upgrade, but that do not strictly require a hard fork. The full agenda is here: https://github.com/monero-project/meta/issues/655
17:01:01 <ErCiccione> for reference, the logs of the last meeting are here : https://github.com/monero-project/meta/issues/633
17:01:16 <ErCiccione> See also this excellent overview of the v15 hard fork: https://github.com/monero-project/meta/issues/630
17:01:20 <ErCiccione> So let's start with a round of greetings to see who is here today.
17:01:24 <ErCiccione> Hey everyone, thanks for joining.
17:01:31 <ArticMine> Hi
17:01:32 <vtnerd_> Hello
17:01:34 <rbrunner> Hello
17:01:44 <jberman[m]> :waves:
17:01:54 <xmrscott[m]> Hello
17:02:34 <Rucknium[m]1> Hi
17:03:53 <moneromooo> hi
17:04:16 <ErCiccione> Ok, let's proceed to the second point of the agenda:
17:04:25 <carrington[m]> Howdy
17:04:30 <UkoeHB> hi
17:04:37 <ErCiccione> 2. Ringsize 16. There were still some doubts during the last dev meeting. Do we want to confirm 16 as the next ringsize or more discussion is needed?
17:04:52 <ArticMine> I say confirm
17:05:20 <Scalability> +1
17:05:35 <rbrunner> +1
17:05:56 <rbrunner> Such a nice number :)
17:06:15 <selsta> we also have to talk about multisig which currently isn't in the agenda as far as I can see
17:06:29 <UkoeHB> ok with me, would have comparable verification costs to a likely seraphis implementation
17:06:40 <xmrscott[m]> +1
17:06:54 <rbrunner> selsta: It's in 5.
17:07:18 <rbrunner> But sure a candidate for 3.
17:07:48 <selsta> IMO it should be something we want to release before the hardfork
17:07:48 <ErCiccione> yeah multisig doesn't require a hard fork, so we can discuss it later. Very important topic indeed
17:08:01 <Rucknium[m]1> I support increase of ring size to 16.
17:08:12 <selsta> but yes lets talk about it later
17:08:27 <Scalability> 16 ring size it is then, no?
17:08:44 <ErCiccione> everyone present agrees on 16. That was easy. We can make it official at this point
17:08:48 <ErCiccione> 16 it is
17:09:23 <ErCiccione> now let's talk about the r PRs that require a hard fork that still need to be merged:
17:09:33 <ErCiccione> 3a. view tags (https://github.com/monero-project/monero/pull/8061).
17:09:41 <ErCiccione> The review of the PR seems to be still ongoing. @jberman could you give us an update of where things stand at the moment?
17:10:01 <UkoeHB> We got some feedback about Siphash, from the Siphash author, on the view tag PR: https://github.com/monero-project/monero/pull/8061#issuecomment-1024939341
17:10:49 <UkoeHB> jtgrassie and vtnerd_ were the ones expressing skepticism about it originally
17:12:06 <jberman[m]> Commit coming today in response to rbrunner 's comments related to making sure there is a smooth transition at the fork (users who update wallets before the fork will have their tx's processed without view tags for a grace period, to allow smooth transition, and will include a way to not cause a breaking change on one of the internal structs)
17:12:36 <rbrunner> Eagerly awaiting this!
17:12:37 <jberman[m]> + addressing their other comments
17:13:05 <jberman[m]> there will also be merge conflicts between this PR and bulletproofs+, happy to take care of them
17:13:38 <ErCiccione> Sounds good. Will it only need final reviews + merge after or are there other blockers?
17:13:38 <rbrunner> I have the code of this PR running at my MoneroTech web wallet as "TechNet" as a functional test. Works beautifully.
17:14:18 <jberman[m]> regarding the re-opening of Siphash versus Keccak discussion, whatever is decided there is super simple to change in the code. I already have the code using Siphash written
17:15:30 <moneromooo> Without knowing the background, switching to a custom hash for only 1% or 2% speedup seems odd.
17:15:41 <UkoeHB> To resolve that question, hopefully jtgrassie and/or vtnerd_ can respond to Mr. Aumasson
17:15:55 <rbrunner> Personally I would like to forego that re-opening ...
17:16:02 <jberman[m]> > Will it only need final reviews + merge after or are there other blockers?
17:16:02 <jberman[m]> some downstream ecosystem folks will likely need new code to to handle view tags (wallets will need to use new code to construct/scan for tx's with view tags)
17:16:29 <jberman[m]> - I don't know the extent of what changes will need to be made to accommodate them it will vary by software (not sure how much is re-used from the core repo)
17:16:29 <jberman[m]> - these changes can likely need to be done alongside changes to support bulletproofs+ I would think
17:17:49 <ErCiccione> got it. Usually we give enough time to members of the ecosystem to adapt to the post-hard fork changes, so that shouldn't be an issue.
17:18:05 <rbrunner> So good we publish the software 1 month before hardfork, right?
17:18:16 <selsta> yes
17:18:30 <ErCiccione> if there are no further comments let's proceed to the next PR:
17:18:38 <UkoeHB> View scanning is a central UX bottleneck, so I think it would be unwise to leave any inch on the table, for no compelling reason.
17:19:30 <ErCiccione> 3b. Fee changes from Articmine (https://github.com/monero-project/monero/pull/7819)
17:19:37 <ErCiccione> The PR seems to be mostly ready and reviewed. Only some minor conflicts that need to be fixed. moneromooo could you give us a quick update?
17:19:53 <selsta> UkoeHB suggested a second review
17:19:59 <moneromooo> AFAIK this is ready. Let me go see the last comments...
17:20:30 <rbrunner> "second review" as in "more eyes"?
17:20:31 <moneromooo> Yes, nothing since, so nothing to add.
17:20:38 <UkoeHB> IMO all big PRs need at least 2 reviewers.
17:21:09 <jberman[m]> I can review this
17:21:10 <carrington[m]> Are the growth numbers from Justins comment here accurate? If so, I have grave concerns about chain growth attacks
17:21:10 <carrington[m]> https://github.com/monero-project/research-lab/issues/70#issuecomment-785193630
17:22:01 <carrington[m]> Especially in light of the flood attack last year
17:22:11 <UkoeHB> My estimate is Monero won't be able to realistically exceed Bitcoin volume: https://github.com/monero-project/research-lab/issues/91#issuecomment-1018641072
17:22:20 <jberman[m]> I'll review 7819
17:22:23 <UkoeHB> Might be worth contemplating an upper limit on block size
17:22:28 <ArticMine> No
17:22:34 <UkoeHB> To avoid stability problems around verification costs
17:22:45 <ArticMine> This has caused very serious problems for bitcooin
17:22:46 <ErCiccione> thanks jberman 🙂
17:22:57 <ArticMine> Thanks jberman
17:22:59 <UkoeHB> ArticMine: bitcoin doesn't have a verification bottleneck
17:23:03 <carrington[m]> The combination of allowing 14x growth in block size per year with the very low fees could lead to a disaster
17:23:10 <ArticMine> Verification can be addressed
17:23:15 <UkoeHB> How?
17:23:36 <ArticMine> With the use of graphic processors and multithreding
17:23:52 <UkoeHB> That only kicks the can, it doesn't solve it
17:24:03 <ArticMine> Actually it does
17:24:23 <ArticMine> once we take a hard look ant the numbers
17:24:43 <UkoeHB> your next project...?
17:24:43 <ArticMine> The overall limit is bandwidth by the way
17:25:03 <ArticMine> I have been looking hard at this
17:25:44 <UkoeHB> In any case, answering this question is the same as 'contemplating the need for a block size limit'. Let's not answer it in this meeting.
17:26:46 <UkoeHB> However, does it need to be answered before the fee PR can be merged? carrington[m] 's concerns
17:27:12 <carrington[m]> Limiting verification to GPU owners is a TERRIBLE tradeoff IMO. Dynamic block size is fantastic up to a point, but there are other ways to scale transactions.
17:27:29 <rbrunner> Well, what's allowed *now* as a yearly blocksize growth?
17:27:34 <luigi1111w> hello i'm sorta here
17:27:44 <ArticMine> Most consumer device have intergrated graphics that can be used
17:27:59 <selsta> most servers don't
17:28:02 <selsta> by default
17:28:17 <rbrunner> And drivers can make you crazy.
17:28:47 <ArticMine> No with current tools such as Open CL
17:28:47 <xmrscott[m]> Also agree limiting to GPUs is a bad idea especially given current shortage of them
17:28:50 <UkoeHB> rbrunner: I think the longterm median can rise 5x per year with current growth rate
17:29:08 <carrington[m]> Reminder that last year someone added 700MB to the block chain for $1000 in fees
17:29:35 <ArticMine> Yes but no on a sustained basis this is the reason for the long term median
17:29:48 <ArticMine> The cosst of the kind of span adds up
17:29:53 <ArticMine> spam
17:29:56 <carrington[m]> https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60
17:30:20 <UkoeHB> The short-term can rise up to 50x the long term. So you could have 75MB blocks after one year of maximal growth.
17:30:26 <ArticMine> I mean in that example the LT median dod not even move at all
17:30:47 <ErCiccione> seems like there are some heavy skepticisms about this. Maybe it needs more focused discussion before we include it in a network upgrade?
17:31:08 <selsta> or a separate MRL meeting for this?
17:31:29 <ArticMine> It has been hashed over and over agan
17:31:43 <UkoeHB> The fee PR is necessary, the question is about growth rate.
17:31:49 <carrington[m]> 100%
17:32:15 <ArticMine> The growth rate of the LT median is necessasry over the short term
17:32:26 <ArticMine> 2 - 3 months
17:33:05 <ArticMine> Any dynamic blocksize can be scaled to insane limites given enoght time
17:33:14 <ArticMine> insane limits
17:33:39 <Scalability> think the fee PR has been discussed for months since artic first came up with it. similar to beating a dead horse. beyond deliberating further, why not run a quick poll for yes or no and move forward depending on the outcome? akin to how we reached final consensus re: ring size bump 16.
17:33:46 <Scalability> just sayin.
17:33:48 <ErCiccione> Clearly more discussion is needed, let's have this discussion in a dedicated MRL meeting, let's move on to the next point
17:33:50 <jberman[m]> I agree a cap of 14x/yr seems high, and I agree it would be ideal to target CPU's to allow syncing on any commodity device, raspberry pi or server included. I'm for another MRL meeting to discuss
17:34:20 <ArticMine> commodity devices have graphics
17:34:24 <carrington[m]> As Justin pointed out, hitting a growth ceiling doesn't break the network. It just causes a temporary fee market. We don't have to rely on a fee market to exist like BTC, but avoiding it completely in exchange for huge chain bloat is nonsensical to me.
17:34:45 <ErCiccione> please set a date for a focused discussion on this, we need consensus on such important change and until that's reached, there is no point in discussing it here. Moving on:
17:34:46 <carrington[m]> Sorry, JustinE to be clear
17:34:57 <ArticMine> Actually it can trigger the issue 70
17:35:16 <UkoeHB> There is a point where normal node operators have to shut down, since they can't verify new blocks fast enough. And also a point that happens way earlier than that, where normal node operators can't verify the chain, since it takes too long to catch up. These breakpoints are stability issues for the network, and they have NOT been discussed.
17:35:24 <ArticMine> If we allow the st median boe be above the lt median for an extend pereiod of time
17:35:32 <Rucknium[m]1> Would it be advisable to implement a slightly more complicated blocksize limit function to permit short-term spikes (to accommodate sudden adoption), but not allow huge cumulative growth over long periods?
17:35:47 <ArticMine> That is what the LT median does
17:35:52 <UkoeHB> Ok ErCiccione we will address it in the next MRL meeting.
17:36:13 <ErCiccione> yes please, let's move on
17:36:15 <carrington[m]> This seems like a good problem for that guy who was looking into the difficulty adjustment recently, control theory and all that
17:36:21 <ErCiccione> 3c. Bulletproofs+ (https://github.com/monero-project/monero/pull/7170)
17:36:32 <ErCiccione> Not much action on the PR lately. Are we waiting for more reviews moneromooo?
17:36:35 <moneromooo> Why ? Come on, they're discussing something importand and on topoc.
17:36:45 <moneromooo> At least wait till they're both done.
17:37:12 <selsta> ErCiccione: vtnerd is working on the review
17:37:37 <ErCiccione> moneromooo: we have a lot of point in the agenda and this is a discussion that has been going on for a long time. If we want to use this meeting to discuss this sure, but i think the hard fork is more importna, especially because we are already postponing it 
17:37:57 <UkoeHB> moneromooo: could you amend the PR comment for 7170 with a link to the audit report on BP+?
17:38:55 <moneromooo> Gah, november, ping me if you comment on a PR from me :S
17:39:08 <ErCiccione> there is always time at the end of the meeting to discuss whatever, but at least let's try to organise this HF first
17:39:13 <moneromooo> I dio not have the audit report. No idea where it is.
17:40:13 <UkoeHB> moneromooo: https://suyash67.github.io/homepage/assets/pdfs/bulletproofs_plus_audit_report_v1.1.pdf
17:40:19 <moneromooo> ty
17:41:00 <ErCiccione> ok, so waiting for vtnerds final review and then can be merged i guess
17:41:28 <selsta> yes
17:41:42 <ErCiccione> so, the situation is: 2 of the 3 PRs that require a hard fork are mostly ready to go. The issue is with the fee changes, since there seems to be some disagreements.
17:42:09 <ErCiccione> Do we feel comfortable in already talking about dates or we want the discussion about the fee changes to be completed first?
17:42:18 <carrington[m]> To clarify, the theory AND implementation of BP+ have been audited, yes?
17:42:35 <selsta> yes
17:43:36 <ArticMine> The fee changes are predicated on the LT median scaling
17:43:51 <jberman[m]> I think it makes sense to wait until the fee change discussion is completed so we don't end up putting out more conflicting dates
17:44:03 <Scalability> discussion re: fee changes is to occur wednesday next week. there are three other potential PRs that could be included before hf as per agenda
17:44:12 <ArticMine> So we need to dealt with fee change dicussin before we proceed with the dates
17:44:21 <ArticMine> for the HF
17:44:21 <selsta> it would be good to have bp+ merged soon so that we can contact hardware wallets for integration
17:44:32 <ErCiccione> jberman: my feeling too
17:44:37 <carrington[m]> A dedicated MRL meeting sounds good, I'll be there
17:44:46 <dEBRUYNE> <selsta> it would be good to have bp+ merged soon so that we can contact hardware wallets for integration <= +1
17:44:50 <ErCiccione> let's freeze the hard fork until the fee discussion is completed then
17:45:00 <dEBRUYNE> We need to be aware that third-party wallets may also require code changes
17:45:13 <dEBRUYNE> So they need to be properly informed of the changes (view tags and BP+)
17:45:31 <ErCiccione> yeah we will do the usual code freeze
17:45:34 <ErCiccione> + let everyone know.
17:45:44 <ErCiccione> *plus let everyone know
17:45:52 <jberman[m]> I'm happy to assist any ecosystem participants with needed changes too
17:46:07 <dEBRUYNE> Right, but want to point out that we may have to allot a bit more time
17:46:20 <dEBRUYNE> Or we need some people dedicated to reaching out and assisting (thanks jberman[m] for offering already)
17:46:46 <carrington[m]> To confirm, if wallets haven't implemented viewtags at the hardfork will their slower previous method continue to work?
17:47:01 <UkoeHB> yes
17:47:18 <ErCiccione> dEBRUYNE: I think we are in a good spot, we have more people that could help compared to the past hard fork. ANd things went always fine in past
17:47:27 <selsta> most normal wallets use wallet2 so it should be a non issue for them
17:47:27 <moneromooo> That explains why it's a candidate for a fork so fast. Nice :)
17:47:57 <jberman[m]> UkoeHB: wallet scanning could still work in theory, but parsing/serializing will probably cause issues. Plus, if we require view tags as the PR does, then they won't be able to construct tx's
17:48:11 <UkoeHB> true
17:48:39 <jberman[m]> the PR as is has a grace period, which I think moneromooo you were intended for BP+ as well?
17:48:42 <dEBRUYNE> ErCiccione: True, but still would like it to go as orderly as possible and not cause any users to not be able to properly use their wallets
17:48:55 <jberman[m]> sorry, willl have a grace period
17:49:00 <ErCiccione> dEBRUYNE: of course. 100% agree
17:49:08 <Scalability> any comments re: multisig PR? https://github.com/monero-project/monero/pull/7877 UkoeHB vtnerd_
17:49:22 <moneromooo> I don't remember whether I added a placeholder fork. A double fork is probably best.
17:49:44 <jberman[m]> https://github.com/monero-project/monero/pull/7170/files#diff-f7570aa4359fd6b0d59a74fbd2d314d06e48a4ffb2475f97e2193b968833abffR74-R75
17:50:04 <ErCiccione> yeah double fork is what we did in past no? 1 fork adds the changes the other one enforces them?
17:50:12 <UkoeHB> I believe vtnerd_ needs final approval, and h4sh3d also said he is reviewing the changes I made.
17:50:13 <vtnerd_> Reviewing it, probably a ship it soon
17:50:14 <moneromooo> When needed, yes.
17:50:17 <ErCiccione> Scalability: will talk about that in a bit
17:50:30 <jberman[m]> I have a commit for view tags will submit today that also implements double fork
17:50:48 <Scalability> thanks vtnerd_ UkoeHB.
17:50:54 <jberman[m]> what do we want the spacing in between forks to be?
17:50:59 <dEBRUYNE> ErCiccione: Yes
17:51:00 <moneromooo> Oh, that reminds me there was a bug with txes being checked when added to the pool before a fork, and not checked again at the fork.
17:51:15 <moneromooo> Did that get merged ? I had a patch for this IIRC.
17:51:19 <selsta> yes
17:51:22 <selsta> it got merged
17:51:27 <moneromooo> Thanks
17:51:29 <jberman[m]> that was merged: https://github.com/monero-project/monero/pull/7169
17:51:54 <moneromooo> Your lookup speed is commendable :o
17:52:33 <jberman[m]> hehe, I have these links from discussion with rbrunner in the view tag PR, who pointed out my view tag PR should also implement the double fork thing
17:52:38 <selsta> luigi1111w: regarding the multisig crypto changes https://github.com/monero-project/monero/pull/8149, any news regarding extra review? you added the important label :D
17:52:54 <luigi1111w> that's cuz it's important :D
17:53:06 <luigi1111w> I hear someone is reviewing it, need to figure out their schedule though yet
17:53:34 <rbrunner> Would be really nice to get the whole multisig stuff into the hardfork as well, for organizational reasons: Everybody will have to update.
17:53:41 <luigi1111w> jberman[m] we should already double fork for ring size/bp I think, so it's ok
17:53:53 <luigi1111w> rbrunner agreed, would really like to see all the ms fixes we have included
17:54:18 <ErCiccione> rbrunner: yeah absolutely, we will need them for Haveno too, so the faster is in, the better
17:54:51 <rbrunner> I made a lot of functional tests with them, up to 3/5 multisig, which all worked
17:55:02 <jberman[m]> (the consensus rules I initially included for view tags didn't follow the double fork pattern is what I meant)
17:55:04 <rbrunner> Does not replace reviews, of course, but still
17:55:47 <ErCiccione> ok, there are other PRs that are marked as nice to have for the HF:
17:55:59 <ErCiccione> https://github.com/monero-project/research-lab/issues/88
17:56:10 <ErCiccione> https://github.com/monero-project/monero/pull/7760
17:56:17 <ErCiccione> https://github.com/monero-project/monero/pull/6410
17:56:32 <ErCiccione> meeting time is almost over, so if anyone has anything to say about any of these, please go ahead
17:56:37 <jberman[m]> Re: multisig, In the past I said I'd review, but I don't have the crypto knowledge to spot significant issues. h4sh3d  I think is currently re-reviewing changes and does
17:56:54 <selsta> jberman[m]: can you give an update on binning?
17:56:59 <selsta> I think it's not planned for this HF
17:57:06 <selsta> if I remember correctly
17:57:22 <jberman[m]> The algorithm in the linked issue is in a state where it is review-able. Personally I don't feel I have compelling enough evidence to push it further i.e. it is not a critically necessary update in my opinion, and needing to find agreement on its parameter choices + getting the implementation into the code seems a tall task considering
17:57:44 <selsta> so yes, I would remove it from the HF list
17:58:25 <rbrunner> It's probably much too late to even try to get 7760 in, no?
17:58:31 <selsta> https://github.com/monero-project/monero/pull/7760 fixes so many existing bugs with the daemon it would be really nice to include it but I don't know yet how we will get it reviewed
17:58:54 <selsta> but it's not something that requires a HF
17:59:01 <ErCiccione> It's stuff that can be done regardless of the HF afaik, so it's ok
17:59:58 <moneromooo> Maybe in a .1 right after the release ? That way it can get long term testing by people who update to it, but most merchants etc won't.
18:00:36 <moneromooo> Though I guess it'd interfere with the usual brown bag fixes.
18:00:48 <h4sh3d> Jberman[m]: ukoeHB: I’m on it, I think I can complete the re-review by the end of next week
18:00:55 <rbrunner> So the fork release becomes something like an LTS release :)
18:00:58 <selsta> I have been running it on my nodes for half a year now
18:01:00 <Scalability> awesome, thanks h4sh3d
18:01:02 <jberman[m]> ^that sounds good to me
18:01:02 <selsta> it's stable :D
18:02:04 <ErCiccione> Nice! Anything else hard fork related? Otherwise we can end the meeting, as we are past the hour
18:02:18 <moneromooo> For the fee issue, could the people who see a problem make a sample case (ideally worst case with ArticMine's current patch and worst case they'd be grudgingly OK with), then ArticMine can see whether he'd be happy with a parameter change that'd prevent those cases while still allowing enough growth ?
18:02:39 <Scalability> view tags and bp+ almost ready to be shipped. fee pr to be discussed during mrl meeting next week. binning post-poned for now. it's looking good as far as i can tell...
18:03:09 <Scalability> ErCiccione: i guess it would be wise to decide if we will have a follow up dev meeting next week, or in two weeks, to hopefully pick dates for hf?
18:03:43 <selsta> multisig is also ready, just getting some extra reviews
18:04:01 <ErCiccione> No need for a follow up meeting until the situation of the fee changes is clarified and consensus is reached IMO
18:04:16 <Scalability> that is what the MRL meeting on wednesday is there for...
18:04:28 <Scalability> there will be consensus because that is an hour long meeting run by UkoeHB.
18:04:38 <UkoeHB> We will see
18:04:51 <Scalability> if you want to be conservative, why not schedule the next dev meeting for dates in two weeks instead of one?
18:05:01 <Scalability> either way there has to be another dev meeting. dates are to be decided still
18:05:02 <ErCiccione> this is a discussion that has been ongoing for months, don't assume it will be clarified in one meeting
18:05:11 <ArticMine> <moneromooo> For the fee issue, could the people who see a problem make a sample case (ideally worst case with ArticMine's current patch and worst case they'd be grudgingly OK with), then ArticMine can see whether he'd be happy with a parameter change that'd prevent those cases while still allowing enough growth ? Could this be posted to MRL issue 70 
18:05:28 <ErCiccione> I don't think there are the basis to schedule another HF dedicated meeting at the moment
18:05:32 <Scalability> not assuming. it's been discussed for months. decisions have to be taken.
18:05:39 <Scalability> OK.
18:05:54 <ArticMine> and cross referenced to pull 7819
18:06:02 <carrington[m]> I'll reread all the relevant threads etc. so I can have an informed opinion on Wednesday
18:07:06 <ErCiccione> Ok the meeting is over folks. Thanks a lot for joining, next appointment is at the next MRL meeting, where fee changes will be discussed, but feel free to continue the conversation here now!
18:07:28 <UkoeHB> thanks ErCiccione 
18:08:26 <carrington[m]> Thank you ErCiccione  , high quality meeting
18:08:39 <rbrunner> +1
18:08:58 <dEBRUYNE> Thanks for hosting/leading the meeting ErCiccione!
18:09:01 <jberman[m]> +1
18:09:14 <ErCiccione> thanks 🙂
18:09:59 <one-horse-wagon[> +1
18:11:14 <carrington[m]> I'll post the logs
18:25:37 <ErCiccione> <moneromooo> "Maybe in a .1 right after the..." <- This is a good idea IMO
18:27:03 <moneromooo> That's what we did for... something, some... time ago. Can't remember what or when, but pretty sure we did :D
18:32:38 <jberman[m]> Ah ya, I remember that was discussed in this vid: https://www.youtube.com/watch?v=dQw4w9WgXcQ
18:34:07 <ErCiccione> :P. jberman matrix preview ruins it 🙂
18:34:07 <jberman[m]> couldn't help it
18:34:47 <jberman[m]> for the IRC people :D
18:35:48 <SerHack> .-.
18:39:32 <ArticMine> https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60 <---- Blocksize remained well below the minimum penalty free zone of 300,000 bytes during the anomaly. https://bitinfocharts.com/comparison/size-xmr.html#log&1y Going into the penalty zone above 300,000 means a 5x increase in fee just to get started. Then there is the requirement to maintain 
18:39:33 <ArticMine> the ST median for over 2 months just to move the LT median
18:40:45 <ArticMine> It is not that simple
18:41:36 <ArticMine> In any case the "attacker" stayed well away from the penalty. 
19:19:20 <sethforprivacy> Sadly missed the meeting, but thanks ErCiccione for hosting it! Will have to read through the logs and catch up.
20:03:18 <dEBRUYNE> carrington[m]: Would you mind posting them on r/Monero as well?
20:03:22 <dEBRUYNE> (the logs that is)
20:35:48 <carrington[m]> Yes I'll make a post shortly
20:46:26 <carrington[m]> ArticMine @ArticMine:libera.chat:  my point with that article was more broadly "low fees are already a problem". Extrapolating, it seems that someone could grow the blockchain by 1TB for roughly $1.5 million without activating dynamic blocksize at all. If dynamic blocksize "organically" results in x14 blocksize over a year, that attack could be performed x14 times faster with a linear cost increase. These costs seem unacceptably low to
20:46:26 <carrington[m]> trash the network completely. Please correct me if I've misunderstood.
20:47:39 <carrington[m]> But then again I'm not sure what the cost of a 51% attack is at the moment, which is what it should be compared to
20:52:57 <carrington[m]> I.e. the attack over the course of a few weeks becomes possible over a few days, leaving not enough time to upgrade hardware and knocking many nodes offline
20:54:30 <ArticMine> Let us start with the current minimum fee. In order to have reliable scaling one needs an increase of 5x
20:56:49 <ArticMine> Now if there is organic scaling to say 32x. or ~100x the current tx rate. What is the impact of price in terms of constant USD?
21:00:07 <ArticMine> I did an analysis of this back in 2020 for a talk I gave on line. For Monero the value increase exponent is about 1.6 This is between 1 (linear) and 2 quadratic Metcalfe's lwa 
21:00:53 <ArticMine> so we are talking about 1600x for the value of 1 XMR
21:04:45 <ArticMine> So one needs to estimate the cost of doubling the block size via spam from say a base of 10 MB
21:05:40 <ArticMine> vs the current situation
21:06:08 <carrington[m]> So the premise is that the base fee would be higher in fiat terms, increasing the cost of such an attack? I will watch your talk before Wednesday 
21:06:49 <gingeropolous> i wonder if we could harvest difficulty / time to get a sense of the verification capability of the network. ... somehow tie the dynamic blocksize to difficulty...  
21:07:21 <ArticMine> The total cost of increasing the blocksize by 2x not the base fee
21:07:42 <ArticMine> The base fee per byte is actually less in terms of XMR
21:08:46 <ArticMine> and can even fall in terms of USD at the expense of lowering the rate of growth
21:09:56 <carrington[m]> gingeropolous @gingeropolous:libera.chat:  isn't difficulty related to hashrate which is not necessarily verifying transactions? 
21:10:20 <ArticMine> For a constant rate of growth the base fee falls be a 32 for the same rate of growth
21:10:30 <ArticMine> in my example 
21:11:26 <gingeropolous> carrington[m], yeah. my point isn't to tie it directly to difficulty, but to use those data as an "oracle", almost, to get a sense of what silicon can do
21:11:42 <ArticMine> for an increase of 32X in blocksize 
21:14:03 <gingeropolous> like if we see a 32x increase in blocksize, but not an X increase in difficulty...thats different than seeing a 32x increase in blocksize and a Y increase in difficulty. 
21:14:28 <ArticMine> At the bare minimum rate the fee in terms of XMR falls by a factor of 1024 in terms of XMR
21:15:49 <ArticMine> So in my scenario of 10 MB blocks with a 1600x in crease in price we have
21:18:48 <ArticMine> Cost of HAM (single tx) at minimum fee the increase in constant USD 5x1600/1024 7.8x The SPAM cost increase by an additional factor of 32
21:19:01 <ArticMine> so 250x
21:19:40 <ArticMine> The current rate
21:21:53 <ArticMine> The bottom line organic growth makes it way more expensive to spam the network once we factor in a reasonable increase in price. 
21:24:01 <carrington[m]> There is a lot to think about here. It definitely seems like an area that would benefit from gaming out various attacks and comparing their cost to a 51% attack. I'm not sure I'm convinced by the "fiat spam price will increase under organic growth" argument (just looks at organic growth over the last year and overlay the fiat price, the correlation is not easy to see).
21:24:01 <carrington[m]> UkoeHB's comment on issue 70 is a good summary 
21:25:27 <carrington[m]> In fact, Moneroans often like to contrast the price charts with the txn increase charts
21:26:07 <ArticMine> It is unsustainable over an extended period of time
21:26:23 <ArticMine> Even if one just consider the equation of exchange
21:27:57 <ArticMine> https://en.wikipedia.org/wiki/Equation_of_exchange One cannot simple keep increasing economic activity, have an effectively constant money supply and not have serious deflation 
23:11:27 <wernervasquez[m]> Is there a good link where I can read up on what the issues are regarding the fee that are being discussed here?
23:12:50 <carrington[m]> wernervasquez:  https://github.com/monero-project/research-lab/issues/70
23:47:59 <geonic> please define "a reasonable increase in price" :-)