10:12:36 <AMeMario> What is Tari?
10:19:24 <AMeMario> Monero inflation bug? boards.4channel.org/biz/thread/26234830
10:35:48 <sgewehr> What kind of person steals from own community?shorturl.at/jmDM4Your own leaders are laughing at how stupid you are for falling for thier 'Magical Crypto Friendship'.
16:43:32 <sgp_> Meeting in ~15
17:00:11 <sgp_> MRL meeting time
17:00:13 <sgp_> https://github.com/monero-project/meta/issues/544
17:00:20 <sgp_> 1. Greetings
17:00:25 <ArticMine> Hi
17:00:56 <TheCharlatan> Hey
17:01:25 <sgp_> ping knaccc sarang dEBRUYNE Isthmus moneromooo
17:01:45 <sgp_> some people may show up after Biden's speech (happening now)
17:02:11 <zkao> hello
17:02:21 <sgp_> before then, I will give a brief BP+ update
17:02:42 <sgp_> sarang gave me some emails to contact asking for SoWs, and I will email them today
17:02:49 <lederstrumpf> hi
17:03:06 <sgp_> the other BP+ audit was moved, funded, and started since last meeting so that's quick
17:03:31 <sgp_> any questions on BP+ audits before we move on?
17:04:02 <ArticMine> Any idea on timeline
17:06:24 <sgp_> "about 1 month"
17:06:39 <ArticMine> Thanks
17:07:29 <sgp_> okay, let's actually skip to v15 ringsize if sarang isn't here to discuss triptych
17:07:38 <ArticMine> Yes I agree
17:07:43 <sgp_> https://github.com/monero-project/research-lab/issues/79
17:07:54 <sgp_> there are a few different opinions on this one
17:08:27 <sgp_> I personally think a bump from 11->15 is most appropriate
17:08:42 <sgp_> ArticMine: you suggest a higher number ~19-25 still, right?
17:08:45 * dEBRUYNE here
17:08:50 <ArticMine> Yes 21
17:09:23 <sgp_> I took a look at the CPU benchmark numbers you shared
17:09:48 <sgp_> the increase you noted was for the high-end hardware that's often out of stock at the moment, from what I can tell
17:10:21 <sgp_> looking at benchmark per dollar, my best estimate is 25% increase
17:10:33 <dEBRUYNE> Wouldn't 21 raise the verification time significantly? Presuming we merely implement Bulletproofs+
17:11:26 <sgp_> I don't have specific numbers for 21
17:11:31 <sgp_> but yes
17:11:38 <ArticMine> I saw your response. I find the high end as the best indicator. Basically "value" is more often than not junk going back to the pc jr in the 1980's.
17:13:04 <ArticMine> One is better off with slightly older high end from a cost vs return perspective than the newest "value"
17:13:05 <sgp_> 15 would increase verification (of the signature and balance, NOT the entire transaction) by 35%
17:13:30 <ArticMine> It is a 2x increase for the signature verification
17:13:32 <sgp_> 17 would increase 54$
17:13:41 <sgp_> *54%
17:13:45 <ArticMine> for 22
17:14:39 <ArticMine> but also it bring the size close to where Triptych would come in
17:15:22 <ArticMine> One thing to keep in mind is that one we go into the dynamic blocksize we have to be very careful how we increase the tx size
17:15:52 <ArticMine> It can be done, but it can require modification of the long term median right after the fork
17:16:18 <dEBRUYNE> I'd prefer to impement a ring size bump with Triptych
17:16:24 <dEBRUYNE> implement*
17:16:41 <sgp_> I think going for a 100% increase in verification is optimistic
17:17:01 <sgp_> I fear it's too aggressive
17:17:12 <sgp_> especially since it doesn't specifically address any threat model
17:17:27 <ArticMine> I am figuring an on triptych coming in with a ring size of ~64 at least
17:17:53 <sgp_> yeah, 64 or 128 (I'll probably push for the latter thinking ahead)
17:18:09 <ArticMine> So a more gradual increase does make sense
17:18:29 <sgp_> well, there are pretty major costs right now for minor benefits
17:18:44 <sgp_> knaccc is for 16 I believe for the churning numbers he shared
17:18:46 <ArticMine> By the way wownero is running ring 22
17:19:16 <ArticMine> Yes that is based upon an arbritary mix set of 1,000,000
17:19:30 <ArticMine> after 4 churns
17:19:31 <sgp_> yeah I agree it's quite arbitrary
17:20:00 <ArticMine> SO there is a gain with each level of increase
17:20:48 <sgp_> just to stress again why I am proposing an increase to begin with:
17:21:10 <dEBRUYNE> I think at 64 the verification time would remain approximately similar right?
17:21:10 <sgp_> 11 is still "safe" in my opinion, but the buffer has narrowed more than I feel comfortable with personally
17:21:24 <sgp_> dEBRUYNE: approximately, yes
17:21:39 <sgp_> https://user-images.githubusercontent.com/12520755/103604734-97fff000-4ed7-11eb-8bc7-76f0044b4e1a.png
17:22:17 <sgp_> sorry that's size not verification time
17:22:30 <ArticMine> The crossover is well above 15 closer to 21
17:23:03 <ArticMine> between CLSAG and Triptych
17:23:40 <ArticMine> more if we extrapolate Triptych to 64 or 128
17:24:31 <ArticMine> Verification time is linear with anonymity size
17:25:00 <sgp_> dEBRUYNE: do you still think keeping it at 11 is best?
17:25:23 <ArticMine> It is still linear with triptych
17:25:34 <dEBRUYNE> As far as I can see, the probability of Triptych getting implemented is fairly reasonable
17:25:38 <sgp_> yeah but is the slope less? iirc the slope is less
17:25:41 <dEBRUYNE> So I am wondering if this discussion is somewhat fruitless in the first place
17:26:02 <sgp_> well, everyone else isn't confident that triptych will happen very soon
17:26:15 <sgp_> signs point to v15 without triptych
17:26:29 <dEBRUYNE> No, but I think end of the year is still a reasonable target
17:26:44 <dEBRUYNE> And to fork merely for Bulletproofs+ seems kind of wasteful
17:26:46 <ArticMine> There are issue with multi sig wallets
17:26:48 <sgp_> so in any case we still have a time v15 without triptych to select a ringsize
17:27:03 <dEBRUYNE> ArticMine: Yes, but nothing that cannot be overcome as far as I can see
17:27:17 <sgp_> it can be overcome but just not hastily
17:27:21 <sgp_> it's a huge change
17:27:31 <ArticMine> ^ that is my point
17:27:36 <dEBRUYNE> Sure, but why the rush to implement Bulletproofs+
17:27:38 <ArticMine> It take time
17:27:42 <sgp_> BP+ is a quite minor change by comparison
17:27:48 <dEBRUYNE> The optimizations are marginal
17:27:51 <sgp_> take the efficiency gain today
17:28:01 <ArticMine> They do add up
17:28:06 <sgp_> taking the gain doesn't delay triptych
17:28:07 <dEBRUYNE> We also have to remind ourselves that the ecosystem grew a lot
17:28:21 <sgp_> if we were pushing triptych back, I would agree
17:28:24 <dEBRUYNE> Not sure if they change the transaction format, but in that case wallets would have to add logic for Bulletproofs+ too
17:28:27 <sgp_> but that doesn't appear to be the case
17:28:29 <dEBRUYNE> (the ones that use custom code)
17:28:48 <dEBRUYNE> Also if we add a HF in say August, we cannot do one for Triptych in say November/December
17:29:01 <sgp_> triptych frankly will not happen in 2021
17:29:06 <ArticMine> There is also issue 70 in mrl
17:29:15 <ArticMine> Tha twill need a hard fork
17:29:18 <dEBRUYNE> That seems like a bit of a preliminary inference
17:29:25 <sgp_> August is also later than it needs to be for BP+
17:29:53 <sgp_> May maybe?
17:30:08 <dEBRUYNE> 5-6 months after our previous HF?
17:30:13 <dEBRUYNE> Which didn't go particularly smooth either
17:30:46 <sgp_> 7 months I guess, could push back more, not technical reason to however
17:30:53 <sgp_> *no technical
17:31:11 <dEBRUYNE> Apart from the fact that it puts a strain on the ecosystem
17:31:17 <dEBRUYNE> It's what was discussed in the blog
17:31:26 <dEBRUYNE> https://www.getmonero.org/2020/09/01/note-scheduled-upgrades.html
17:31:45 <sgp_> I simply do not see triptych as being implemented as optimistically as you
17:32:58 <dEBRUYNE> Perhaps sarang or moneromooo can weigh in, but I think having 9 months is definitely doable
17:34:02 <sgp_> well, moo said they don't want to touch that code, so we would need someone like sarang to start running with it
17:34:14 <sgp_> then we would need to notify everyone of the upcoming change
17:34:28 <sgp_> then we would need to make super clear resources for users of multisig wallets
17:34:37 <selsta> BP+ will require changes to HW wallets, right?
17:34:38 <sgp_> and give them time to coordinate and "convert"
17:35:40 <dEBRUYNE> As far as I know they don't necessarily need to convert existing funds
17:35:45 <dEBRUYNE> Merely generate a new wallet for Triptych funds
17:36:25 <sgp_> we discussed a major issue last week, where they need to "convert" to a non-multisig wallet to spend triptych funds
17:36:40 <sgp_> that conversion period will take a lot of education
17:37:29 <sgp_> point is, unless we have someone ready to run with the idea, we're kinda hoping for something that isn't even penciled in currently
17:37:36 <sgp_> we can work on getting everything outlined
17:37:45 <sgp_> but we don't currently have anyone working on this
17:37:54 <sgp_> nor has sarang said "I will do this if I get the $$$"
17:38:07 <ArticMine> BP+ does not need any of the conversions that Triptych will need
17:38:41 <ArticMine> So I way we need to proceed with BP+
17:38:44 <dEBRUYNE> I suppose we can assess the viability again in a few months, but it also seems to be a bit preliminary to say that we can fork BP+ in summer
17:39:00 <sgp_> well, at that point we lose the efficiency gain anyway haha
17:39:40 <dEBRUYNE> Not sure I am following
17:39:48 <dEBRUYNE> The gain starts counting from the moment it is implemented
17:40:09 <sgp_> I don't want BP+ to be something we delay and hope that triptych will come together in a few months
17:40:22 <sgp_> if we want to commit to triptych, it will take significant active effort
17:40:35 <sgp_> else we're delaying bp+ for no reason
17:40:44 <sgp_> *no significant reason
17:41:36 <dEBRUYNE> I meant that in 1-2 months we probably have a fairer assessment of the viability of Triptych in 2021 (end of)
17:42:26 <sgp_> okay, so what are the specific next steps we need to take to figure that out
17:42:34 <ArticMine> ... but even with say Triptych at the end of 2021 it still makes sens to go ahead with BP+
17:42:43 <ArticMine> sense
17:43:01 <sgp_> ArticMine: if it actually is 2021, I'm less for BP+ right now
17:43:31 <ArticMine> It depends when in 2021
17:43:31 <u29601mg6ba93j[m> I think a definite gain soon (BP+ and ring size increase) is a great hedge against the real possibility that triptych will  take longer than we hope to implement. We can argue about which CPUs to benchmark but ArticMine is right that they have advanced a lot over the past 2 years. That should be accounted for when looking at verification times. The tx size increases are not large enough to be problematic
17:43:31 <u29601mg6ba93j[m> for the ring sizes we are discussing
17:43:31 <sgp_> to dE's point, a 5% gain isn't worth an upgrade headache for that time period, at least imo
17:44:02 <sgp_> that being said, if we feel the ringsize needs to be increased before EOY, then our hands are tied and we should do one earlier
17:44:53 <sgp_> quick vote
17:44:58 <ArticMine> I see as there are enough incremental inprovements to make it worthwhile overall
17:45:24 <sgp_> Do you believe it's critical to increase the ringsize before the end of the year? Y/N
17:45:30 <ArticMine> Y
17:45:34 <u29601mg6ba93j[m> Y
17:45:40 <sgp_> N
17:46:01 <moneromooo> triptych will depend on whether sarang or someone with a similar level of clue either adds it to monero, or adds a *production quality* python implementation that I can convert to C++.
17:47:47 <sgp_> ArticMine u29601mg6ba93j[m: why do you feel that an "immediate" (very soon timeline) ringsize increase is necessary?
17:48:18 <ArticMine> I am also concerned about the regulatory issues
17:48:40 <sgp_> is that the main reason or a side reason?
17:49:29 <ArticMine> It is a major reason. There is also the multiple attack vectors mining, CTRs, etc
17:49:45 <ArticMine> They can have a cumulative effect
17:49:46 <sgp_> I personally don't see a regulatory difference 11 vs (eg) 25
17:50:15 <sethsimmons> <sgp_ "Do you believe it's critical to "> Y
17:50:27 <sethsimmons> Sorry I'm late 🙂
17:50:34 <gingeropolous> Y for me as well
17:50:51 <sgp_> sethsimmons gingeropolous why do you feel it's essential to increase the ringsize Q2?
17:50:57 <u29601mg6ba93j[m> Mostly because we are all guessing about how soon Triptych can be implemented. Moneromooo just mentioned one key dependency (availability of Sarang) that we cannot be certain of yet. We cant go back in time. Skipping BP+ and ring size increases now, will become a regret if Triptych gets delayed for 1 year or more
17:51:44 <u29601mg6ba93j[m>  * @sgp_  Mostly because we are all guessing about how soon Triptych can be implemented. Moneromooo just mentioned one key dependency (availability of Sarang) that we cannot be certain of yet. We cant go back in time. Skipping BP+ and ring size increases now, will become a regret if Triptych gets delayed for 1 year or more
17:52:14 <sethsimmons> <sgp_ "sethsimmons gingeropolous why do"> EOY is still a long ways off and there will surely be new threats to the network by then. As you’ve said, I feel that 11 is OK for the moment most likely, but I definitely would like to see a bump before EOY
17:52:44 <sgp_> is there a date everyone has in mind for "11 really needs to go by then"
17:53:02 <ArticMine> ASAP
17:53:52 <gingeropolous> 1. triptych implementation timeline unknowns. 2. using every opportunity available to strengthen the network within reasonable technical limitations. This goes to my viewpoint that we have enjoyed seemless protocol upgrades and their is no sign of ossification, but ...
17:55:43 <sethsimmons> Takes a good bit of time to plan and deploy a HF across the ecosystem, so ASAP for me as well.
17:56:10 <sgp_> last chance to respond on this q, then I'll ask another
17:56:18 <binaryFate> lurking, I support ASAP for >11 too
17:56:29 <UkoeHB__> I do not think multisig wallets would need to convert to non-multisig to spend Triptych funds, unless Triptych-friendly multisig isn't implemented (it's a non-trivial task)
17:57:40 <sgp_> UkoeHB__: can you read sarang's statements form last meeting and clarify? https://github.com/monero-project/meta/issues/542
17:58:07 <sgp_> second q time
17:58:25 <Lyza> dunno how relevant this would be considered, but there's been a lot of patches recently to address ongoing attacks and a consensus change would make them effectively mandatory which could be a plus
17:58:31 <sgp_> if the decision is to increase ringsize ASAP, how early can we have v15
17:59:07 <sethsimmons> As soon as BP+ is audited and all issues are corrected. Maybe mid-late April?
17:59:09 <selsta> earliest July IMO
17:59:13 <sethsimmons> That may be too soon though.
18:00:28 <dEBRUYNE> As a general comment, I don't like this push for a hard fork 'ASAP'
18:00:54 <dEBRUYNE> We informally decided to slow them down due to the strain on the ecosystem and now I see a few people here pushing again for one within 5-6 months of the previous one
18:01:00 <sgp_> is anyone for a sprint? thinking like April. Just trying to feel this out
18:01:08 <dEBRUYNE> Hard pass from me
18:01:10 <sethsimmons> ASAP as in "as soon as we can reasonably deploy one across the ecosystem".
18:01:32 <ArticMine> Yes of course
18:01:49 <UkoeHB__> sgp_: afaict he said two things A) Triptych multisig is non-trivial and may not work on hardware devices, B) he thought maybe it reveals a private key to all participants but appeared to walk that back here https://monerologs.net/monero-research-lab/20210115
18:02:23 <ArticMine> My take ~9 months since the last HF
18:02:37 <selsta> that would be July / August
18:02:51 <ArticMine> Yes that makes sense to me
18:02:55 <knaccc> btw I don't have a strong opinion yet on ring sizes, because I'm not sure what the stats will look like on verificaiton times for a year's worth of blockchain
18:02:58 <sethsimmons> I'd get behind July/August.
18:02:58 <sgp_> I agree that if we are waiting until that time, we have a few weeks to put together a triptych plan
18:03:12 <sethsimmons> Don't want to make things too painful for ecosystem participants.
18:03:38 <gingeropolous> so July / august would put us at April 2022 for triptych if we're gong for ~9 months in between
18:03:47 <sgp_> If we can get triptych in Dec 2021 actually, then I personally think that's better than BP+ in July/August
18:03:48 <dEBRUYNE> Does BP+ change the transaction format by the way?
18:04:01 <dEBRUYNE> UkoeHB__ ^
18:04:14 <sethsimmons> <sgp_ "If we can get triptych in Dec 20"> If that's possible I could get behind that. But that seems highly optimistic.
18:04:34 <sgp_> the main reason to do v15 quickly is if the current ringsize is determined to be unsafe (think like an emergency)
18:04:36 <selsta> dEBRUYNE: yes, afaik Trezor will have to update their firmware and Ledger update their app
18:04:38 <UkoeHB__> not sure dEBRUYNE
18:04:46 <selsta> at least I think so
18:05:14 <sgp_> if we're thinking an increase many months away, that doesn't seem to me like people think it's an emergency
18:05:17 <gingeropolous> but BP+ also works for triptych right?
18:05:26 <sgp_> gingeropolous: yes
18:06:02 <u29601mg6ba93j[m> <selsta "that would be July / August"> 9 months seems like a good compromise. I would prefer faster but balance that preference to what dEBRUYNE said about challenges for ecosystem  and our goal to decrease fork frequency
18:06:19 <sethsimmons> <sgp_ "if we're thinking an increase ma"> Its not an "emergency", no.
18:06:38 <sethsimmons> Necessity if Triptych is not possible this year, yes IMO.
18:06:52 <sethsimmons> But doesn't require wrecking the ecosystem to get it quickly.
18:07:14 <Lyza> echoing knaccc 's concern.
18:07:14 <Lyza> it keeps being said that the given verification time increases are not for the entire transaction, but those are exactly the numbers that seem most relevant to the verification time discussion
18:07:29 <dEBRUYNE> <sgp_> the main reason to do v15 quickly is if the current ringsize is determined to be unsafe (think like an emergency) <= Is it?
18:07:30 <TheCharlatan> Since bulletproofs+ does not only change proof verification, but also proof creation, it will require a wallet side update.
18:07:34 <dEBRUYNE> I am skeptical of that statement to be honest
18:07:48 <sgp_> if I can summarize things a bit just so we don't talk in circles
18:08:01 <dEBRUYNE> TheCharlatan: Thanks. That means MyMonero etc. need to upgrade too, which will be a hassle
18:08:07 <sgp_> we are a few months away from the soonest anyone wants to have a network upgrade
18:08:08 <dEBRUYNE> Especially if they have to upgrade a few months later again for Triptych
18:08:28 <sgp_> that gives us a small amount of time (not a huge amount!) to feel out a triptych action plan
18:08:48 <sgp_> if within a month we don't have a triptych plan, seems like most people are for BP+ and a ringsize bump in July
18:09:01 <sgp_> since people don't want to drag their feet forever
18:09:33 <sgp_> if however triptych is actually doable by EOY, I see strong arguments for pushing v15 to Dec to not delay Triptych by 6+ months
18:09:48 <Lyza> agree
18:09:54 <sgp_> is the above in contrast to anyone's thinking?
18:09:57 <gingeropolous> that logic seems sound to me as well
18:10:04 <sethsimmons> No, agreed here.
18:10:31 <UkoeHB__> it's reasonable
18:10:36 <sethsimmons> Is initiating HF planning in late Feb/early march sufficient time for forking in July?
18:11:12 <sgp_> imo yes, we need 3 months on the planning side for a relatively "small" upgrade like BP+
18:11:25 <ArticMine> That is reasonable. Aim for July / August and if Triptych is viable by December then delay to include Triptych
18:11:36 <gingeropolous> i would put forth that if triptych is not seen doable by EOY, we consider a ringsize bump without BP+. This would put the least strain on the ecosystem (no 3rd party upgrades etc) but still get everyone on the same software, which re: p2p attacks, is good
18:11:40 <sethsimmons> OK, good with me then.
18:12:15 <sgp_> okay, I will make a visual showing the rough timeline options then
18:12:15 <sethsimmons> <gingeropolous "i would put forth that if tripty"> That's a good alternative but I'd prefer to make the fork "worth it" with some important upgrade like BP+
18:12:36 <sethsimmons> It causes ecosystem strain either way simply HFing, although without BP+ would be lessened.
18:12:39 <gingeropolous> but BP+ is gonna cause 3rd parties to have to fiddle, and then they're gonna have to fiddle again with triptych
18:12:47 <ArticMine> There is also MRL 70 fee stabilization
18:12:59 <gingeropolous> i guess good info would be how ready are 3rd party things to fiddle
18:13:08 <sethsimmons> <gingeropolous "but BP+ is gonna cause 3rd parti"> How significant is this fiddling?
18:13:10 <sgp_> any immediately pressing matters to address at this meeting?
18:13:15 <gingeropolous> ledger, trezor, mymonero
18:13:27 <selsta> all mobile wallets too
18:13:29 <sethsimmons> They all have to update for HF anyways.
18:13:41 <u29601mg6ba93j[m> <ArticMine "There is also MRL 70 fee stabili"> Do you feel that should be done by July fork or can it wait for Triptych?
18:13:41 <TheCharlatan> gingeropolous I don't think that is true r.e. no 3rd party upgrades if only the ring size is bumped. The wallets still need to update to create larger transactions.
18:13:43 <sgp_> to reiterate, my personal action items are: 1) contact for second BP+ audit, 2) make visual of timeline options
18:14:02 <ArticMine> It should be done by the July fork
18:14:31 <u29601mg6ba93j[m> > <@freenode_ArticMine:matrix.org> There is also MRL 70 fee stabilization
18:14:31 <u29601mg6ba93j[m>  * Do you feel that should be done by July fork (if applicable) or can it wait for Triptych (perhaps not until 2022)?
18:14:36 <TheCharlatan> I don't think bulletproofs+ will bring much more fiddling once it is reviewed and in a stable state.
18:14:44 <gingeropolous> ok
18:14:44 <ArticMine> because we could go into the adaptive blocksize and then the recent attack could have bite
18:15:18 <TheCharlatan> The only thing that significantly changes for the hardware wallets will be some message sizes. The bulletproofs are anyway already done by the monero wallet, not the device firmware.
18:15:30 <u29601mg6ba93j[m> <ArticMine "because we could go into the ada"> That is a great point, especially if adoption increases significantly this year
18:15:42 <selsta> TheCharlatan: so less work than CLSAG?
18:15:45 <selsta> that would be good
18:16:01 <TheCharlatan> Yes, definitely less work than CLSAG.
18:16:06 <ArticMine> basically if we are into the adaptive blocksize an attack for a matter of hours can trigger a fee increase that can take months or even years to correct
18:17:00 <ArticMine> There is a real incentive here for an attack similar to what happen recently
18:17:28 <ArticMine> but it only works if we are in the adaptive blocksize not in the penalty free zone
18:17:32 <UkoeHB__> ArticMine: have you published your latest recommendations yet?
18:17:59 <ArticMine> I have them finalized not published yet
18:18:19 <UkoeHB__> cool I look forward to it
18:18:19 <ArticMine> I expect within a week
18:19:07 <u29601mg6ba93j[m> Since it is coming within a week. Can we have another vote next week(same as before except adding MRL70 to the July Bp+ and ringsize increase fork)?
18:19:22 <ArticMine> We can meet in a week
18:19:29 <ArticMine> same time
18:19:38 <dEBRUYNE> Sounds good
18:19:49 <sethsimmons> Thanks all!
18:24:06 <ArticMine> Thanks
18:24:17 <gingeropolous> Thanks everyone!
18:24:22 <sgp_> thanks!
18:26:20 <gingeropolous> ArticMine, is your current work based on testing the existing software? I'm thinking of putting in the effort to actually test the adaptive blocksize stuff using release software
18:27:53 <ArticMine> It is about issue 70 in MRL.
18:28:48 <ArticMine> https://github.com/monero-project/research-lab/issues/70
18:29:03 <ArticMine> Now combine this with the recent attacks
18:29:36 <ArticMine> It only works f we are naturally deep in the adaptive blocksize
18:29:41 <ArticMine> if