17:01:28 -UkoeHB> meeting time: https://github.com/monero-project/meta/issues/611 I will take chair unless someone else steps up
17:01:31 -UkoeHB> 1. greetings
17:01:33 -UkoeHB> hello
17:01:48 -Rucknium[m]> Hi
17:01:49 -rbrunner> hi there
17:01:55 -Halver[m]> Hello
17:01:57 -asdf234[m]> hello! here to watch
17:01:59 -jberman> Hello
17:02:15 -carrington[m]> Howdy
17:03:04 -UkoeHB> Today we will skip updates in favor of agenda items.
17:03:14 -UkoeHB> 2. Improvements to the mixin selection algorithm
17:03:14 -wfaressuissia> Hello
17:03:40 -sethsimmons> Hi all
17:04:13 -gingeropolous> hi
17:04:43 -rottenstonks> waddap.
17:04:56 -Rucknium[m]> Mixin selection algo: I submitted my Vulnerability Response Process submission a week ago. moneromooo has looked at it. Not sure exactly what I can share from that conversation. Anyway, I expect to have a draft CCS by tomorrow or Friday and do the PR thing on the CCS website
17:05:13 -Rucknium[m]> Work is proceeding apace
17:05:34 -Rucknium[m]> jberman has some updates on enforcement of the distribution at the consensus level I think
17:06:13 -jberman> Reminder of 4 areas are:
17:06:27 -jberman> 1. Integer truncation in the wallet (e.g.: 3 / 2 = 1)
17:06:27 -jberman> 2. Binning
17:06:28 -jberman> 3. Modifying the distribution estimator (@Rucknium spearheading this)
17:06:28 -jberman> 4. Validating correct algo used at consenus
17:06:43 -Rucknium[m]> I guess I have also been taking a dip into the literature. The number of papers on Monero has been increasing rapidly. That's part of the agenda item on MRL structure.
17:06:49 -jberman> [1] Integer truncation is still out for review in PR 7798, nothing to update there
17:07:32 -jberman> [2] Binning is still mostly relevant to discuss in context of what to do with timelocks, again
17:08:03 -jberman> [3] Ruck's update clarifies what he's up to there
17:08:54 -jberman> [4] Validating the correct algo used at consensus: I shared a poc for validation at consensus level, but imo it is still premature to get deep into the weeds going through it
17:09:39 -Rucknium[m]> I agree that [4] is going to be very tricky. It will need months of dedicated study.
17:09:46 -UkoeHB> [2] Binning: I think if we want large rings, then this will become a problem if timelocks aren't changed. To reference large rings without any deterministic compression techniques, requires a lot of data. Suppose 100 ring members - at 2-5 bytes per varint offset, this can be 200-500 bytes (vs 20-40 bytes currently with 11 ring members).
17:10:31 -sethsimmons> AFAICT timelocks have no support, and could be removed without any major ecosystem effect.
17:10:39 -gingeropolous> ^
17:10:59 -sethsimmons> I haven't heard from a single person or project that uses them, atomic swaps do not rely on them, and wallets do not normally use/allow them except official CLI.
17:11:06 -UkoeHB> It would be helpful for people to look at the alternative solutions and express opinions/ideas (instead of silently agreeing).
17:11:22 -sethsimmons> I don't think there are any issues with deprecation there.
17:11:27 -Rucknium[m]> Seth For Privacy: jberman has written up some initial thoughts about ecosystem impact here:
17:11:27 -Rucknium[m]> https://github.com/monero-project/research-lab/issues/78#issuecomment-924622985
17:12:01 -jberman> I think the most interesting known use case for it is proof of unspent funds
17:12:10 -jberman> Described there and in that discussion
17:12:23 -carrington[m]> Alternative solutions?
17:12:24 -moneromooo> FWIW I removed unlock_time for all txes except coinbase and nothing broke.
17:12:46 -rbrunner> You mean in a test branch of yours?
17:12:53 -moneromooo> Yes (TF).
17:13:21 -Rucknium[m]> People in r/Monero are railing against Binance and saying that Binance and other exchanges should release info on proof of funds. Could time locks help with that? Just throwing out ideas.
17:13:42 -moneromooo> Proof of balance does not use timelocks.
17:14:04 -noizecore[m]> encryption option sounds like the best bet besides the increase in t size
17:14:15 -noizecore[m]> how much bigger are we talking?
17:14:20 -noizecore[m]> s/t/tx/
17:14:26 -UkoeHB> noizecore[m]: something like 25-50%
17:14:46 -sethsimmons> Just read the jberman details, still all for removal.
17:14:58 -jberman> Right, people/Binance could use that proof of balance (get_reserve_proof) instead
17:15:14 -sethsimmons> The size/verification loss due to encryption is way too major, and leaving un-encrypted goes against a core tenet of Monero -- standardize TXs as much as possible.
17:15:22 -noizecore[m]> UkoeHB: and besides that it has a clear benefit over all other options yeah?
17:15:27 -sethsimmons> Not to mention the issues with binning etc.
17:15:30 -moneromooo> It does leak private info though (ie, which outputs are yours IIRC).
17:16:05 -sethsimmons> Increased dev time and no real use case ATM.
17:16:08 -UkoeHB> it does? I haven't looked at it too closely
17:16:37 -moneromooo> Though that could be mitigated. It uses 1-rings IIRC. Could be made to use 11-rings or whatever else.
17:17:05 -sethsimmons> The encrypted option would involve extra dev work AFAIK.
17:17:15 -moneromooo> In fact, it could use huge rings since we don't really care that much about size or verification time.
17:17:44 -Halver[m]> My understanding is that, if needed, a timelock feature can probably be implemented on the client side.
17:17:44 -Halver[m]> (but I may be wrong ?).
17:17:45 -Halver[m]> So I don't see as crucial to put such a feature in the protocol.
17:17:52 -Halver[m]> s///
17:17:55 -moneromooo> Anyway, for unlock_time, my preference is remove and add later if needed for L2 purposes or the like (and possibly with different semantics).
17:18:22 -gingeropolous> +1
17:18:30 -sethsimmons> moneromooo: Agreed!
17:18:44 -UkoeHB> I also prefer to remove. It is a legacy thing mainly used to lock coinbase outputs (probably added for that purpose originally).
17:19:17 -sethsimmons> Can coinbase outputs be locked another way?
17:19:34 -sethsimmons> What happens to the 60 block lock if unlock_time is removed?
17:19:43 -noizecore[m]> UkoeHB: how would this affect UX?
17:19:44 -sgp[m]> hi all, sorry I'm late
17:19:45 -moneromooo> You could keep it for them.
17:19:46 -sethsimmons> Or can it be used for just coinbase without effecting binning?
17:19:50 -jberman> Just an implementation detail, not an issue sethsimmons
17:20:09 -sethsimmons> Ok, great 🙂
17:20:10 -rbrunner> Just hardcode then?
17:20:15 -UkoeHB> noizecore[m]: it would simplify UX a bit, by removing some options
17:20:35 -jberman> Ok, I think we can move on from timelocks, don't need to take up the whole time on it
17:20:55 -UkoeHB> jberman Rucknium[m] anything else to add about agenda item 2? Points we should put more attention on?
17:20:55 -jberman> Summary: consensus continues to form strongly for removing and bringing back if desired
17:21:15 -Rucknium[m]> No, I am done with item 2
17:21:49 -sgp[m]> moneromooo: +1
17:22:02 -UkoeHB> jberman: ?
17:23:00 -UkoeHB> 3. Analysis of July-Aug 2021 tx volume anomaly
17:23:16 -UkoeHB> isthmus:
17:23:47 -Rucknium[m]> According to my impression, we have produced overwhelming evidence that the tx volume anomaly was due to the actions of a single entity...
17:24:14 -Rucknium[m]> Furthermore, doing so was incredibly cheap if our calculations were correct.
17:24:40 -Rucknium[m]> isthmus seems not to be here right now, but myself jberman, carrington, and gingeropolous have helped
17:24:59 -Rucknium[m]> I think the results will be released within a day or two
17:25:15 -rottenstonks> 👀 single entity?
17:25:16 -Rucknium[m]> But on every metric we looked at, the conclusion seems inescapabale.
17:25:19 -UkoeHB> I think the fee analysis has generally considered spam in the minimum penalty free zone of 300kB to be acceptable.
17:25:27 -carrington[m]> The conclusions are spooky and should motivate a network upgrade ASAP
17:25:29 -sgp[m]> approx how many transactions do you think we created this way?
17:25:49 -moneromooo> "we" ?
17:26:06 -gingeropolous> lulz. prolly "were"
17:26:07 -rottenstonks> as in the monero network?
17:26:20 -sgp[m]> hehe, "were"
17:26:35 -Rucknium[m]> This isn't group consensus, but it is my impression that the characteristics of the anomaly do not fit an actual malicious actor. They better fit an academic researcher or just some greyhat hacker that did it for the lulz (it would have been cheap enough to do it for lulz)
17:27:08 -sgp[m]> what would make you think that
17:27:47 -UkoeHB> It could also be a malicious entity testing things out.
17:27:53 -Rucknium[m]> 1) They did not try to hide their actions at all
17:27:53 -Rucknium[m]> 2) The "flood" wasn't quite enough to seriously harm privacy
17:28:27 -Rucknium[m]> UkoeHB Yes, that is one possibility.
17:28:44 -sgp[m]> I'll wait for the writeup, but I have many other questions still
17:28:51 -rbrunner> Me too
17:28:53 -Rucknium[m]> isthmus thinks that a hardfork, or whatever is needed, needs to come soon to fix the low fee issue.
17:28:54 -gingeropolous> yes .. this is important to discuss, but i dunno how productive this can be if the report isn't available for review etc.
17:29:01 -wfaressuissia> "[4] is going to be very tricky. It will need months of dedicated study." can you define few verifiable metrics that will be improved and can be verified ?
17:29:26 -wfaressuissia> s/and can be verified//
17:29:43 -rbrunner> People probably won't agree that we have a "low fee issue"
17:29:46 -Rucknium[m]> wfaressuissia[m]: That's earlier in the agenda, but what do you mean?
17:29:51 -carrington[m]> Fee increase + ruck and jbermans decoy selection work would go a long way to mitigating such an attack
17:30:34 -Rucknium[m]> A single tx can be like one tenth of one cent, right?
17:31:07 -rbrunner> Would that made such a flood considerably more expensive already?
17:31:11 -UkoeHB> Rucknium[m]: have you looked at the fee cost if tx volume was high enough to eat into the penalty zone? Minimum fees are very very low for a reason.
17:31:50 -sgp[m]> we already have a proposal for the base fee increase
17:31:54 -wfaressuissia> In general, bad decoy selection amplify efficiency of spam attack, but doesn't ideal decoy selection isn't a protection against spam attack
17:32:02 -Rucknium[m]> isthmus did the fee calcs. He said "The anomalous transaction volume was paying standard fees, which at the time was about 0.000015 XMR per transaction with this construction"
17:32:05 -wfaressuissia> s/doesn't//
17:32:14 -sgp[m]> and yeah it's definitely more complicated than base fee * txs, that's 1 thing floodxmr messed up in v1 of their paper
17:32:50 -rottenstonks> https://github.com/monero-project/research-lab/issues/70
17:33:38 -rottenstonks> https://github.com/monero-project/monero/pull/7819
17:33:45 -Rucknium[m]> Sorry, isthmus calcs say that the fee would have been about 0.003USD/tx , not 0.001USD/tx as I stated above. Still, very low.
17:34:18 -sgp[m]> yeah cheap in any case
17:34:24 -gingeropolous> well, that chain needs to be active for ring sigs to do their thing
17:34:28 -gingeropolous> *the chain
17:34:40 -gingeropolous> im just stating obvious things
17:35:45 -carrington[m]> Monero needs to walk the tightrope between fees being low enough to allow a big crowd to hide in, and high enough to prevent flood or big bang attacks. I don't think tx volume would plummet if fees were $0.01
17:35:51 -UkoeHB> > "[4] is going to be very tricky. It will need months of dedicated study." can you define few verifiable metrics that will be improved and can be verified ?
17:35:51 -UkoeHB> I am also curious about this.
17:36:00 -Rucknium[m]> I suppose we can wait until the results are published and then discuss more. I expected publication by now, but there are just so many rabbit holes to go down. There still are, but the rest of the rabbit holes will have to wait.
17:36:15 -Rucknium[m]> UkoeHB: What do you mean by metrics?
17:36:26 -moneromooo> Maths 🙂
17:36:42 -gingeropolous> so, whats the goal here? try and find ways to prevent flood attack? or mitigate the effect of flood attack?
17:36:52 -UkoeHB> he probably means, how to assess if a proposal for enforcing distribution is worth pursuing?
17:37:00 -sgp[m]> can't prevent really
17:37:10 -Rucknium[m]> Do you mean what criteria might be used to enforce the distribution used?
17:37:21 -jberman> [4] is validating tx's ring members match the expected distribution of decoys. It would prevent older implementations of the decoy selection algo from making their way onto the chain
17:37:21 -jberman> We could go through the chain and identify blatantly incorrect rings as a % of all rings
17:37:27 -moneromooo> How will you assess whether a given change is beneficial compared to what we have.
17:37:44 -gingeropolous> to me, prevention is fee based. mitigation is ringsize a bajillion and smarter ring member selection
17:37:45 -moneromooo> (I assume that's what is meant by metrics)
17:37:52 -jberman> openmonero is using a blatantly old implementation of the decoy selection algo that I believe can be fingerprinted
17:38:02 -Rucknium[m]> UkoeHB: We already sort of know it's worth looking at since txs that don't follow the standard can stick out like a sore thumb.l The problem will get worse if and when ring size increases.
17:38:03 -jberman> I think we can identify openmonero tx's
17:39:16 -rbrunner> Somehow I am not quite comfortable with the thought that 1 greyhat hacker or 1 bored dev does some flooding, once, and bang we all already have to pay higher fees ...
17:39:40 -rottenstonks> whoa, whoa. big if true. jberman
17:39:53 -UkoeHB> I think the main cost of enforcing a distribution, as has been mention by others, it lack of flexibility to update decoy selection ad hoc in the face of unforseeable problems. Updating the algorithm inserts an extra dependency on core that isn't savory in the long run.
17:39:59 -sgp[m]> rbrunner: the proposal for this upgrade was written and discussed before this attack
17:40:16 -rottenstonks> rbrunner: did you through MRL 70 yet?
17:40:19 -Rucknium[m]> If a truly malicious party floods the blockchain with txs and therefore owns a huge share of the outputs, they could trace nearly all txs.
17:40:25 -gingeropolous> interesting UkoeHB
17:40:26 -rbrunner> Only a cursory glance.
17:40:27 -carrington[m]> If we had binning we could have deterministic rings without the need for statistical tests, yes?
17:40:32 -rottenstonks> k.
17:40:45 -Rucknium[m]> That's my understanding of what a FloodXMR attack involves
17:40:48 -jberman> That's my understanding carrington[m]
17:41:17 -rbrunner> Well, maybe truly malicious entities can also fees that are quite a lot higher ...
17:41:27 -sgp[m]> okay there are a bunch of different overlapping topics right now being discussed at the same time
17:41:33 -sgp[m]> moneromooo: I want to get back to this
17:41:41 -Rucknium[m]> rbrunner: This is also true
17:42:30 -Rucknium[m]> sgp: I think some ideas have already been floated. We don't have to enumerate all of them. It's an ongoing process.
17:44:45 -Halver[m]> short paper (2014) from MRL about floodXMR
17:44:47 -Halver[m]> https://www.getmonero.org/resources/research-lab/pubs/MRL-0001.pdf
17:45:09 -rbrunner> I wonder how that complicated and time consuming [4] will fare if we are constrained for dev and/or researcher time and have many other important things.
17:45:20 -carrington[m]> We can probably conclude this agenda item I guess? Summary is that anomaly analysis should motivate urgent work towards a network upgrade
17:45:26 -UkoeHB> ok let's get back on track
17:45:26 -UkoeHB> - [4] enforced distribution: TBD needs research (also needs to clearly describe how to evaluate if a proposal to enforce distribution is better than what we have, and doesn't weaken Monero's long-term viability)
17:45:26 -UkoeHB> - fee changes: there is PR #7819 that will probably be mergable by next week or later this week; it will increase base fees, and adjusts the algorithm according to MRL #70
17:45:26 -UkoeHB> - spam: a report is incoming from isthmus
17:45:49 -UkoeHB> 4. Triptych vs. alternatives; any new questions/comments?
17:46:14 -sgp[m]> yes all sounds good koe
17:46:42 -sgp[m]> oh quick update just for visibility
17:46:50 -noizecore[m]> UkoeHB: yes how close are we to a decision? is triptych more or less off the table?
17:46:52 -sgp[m]> on lelantus spark
17:46:55 -UkoeHB> Seraphis has been updated, and Spark is being updated, to fix an issue brought up by nwk (thanks 🙂). It causes a slight efficiency loss, but otherwise is a good step forward.
17:47:34 -sgp[m]> an outside researcher found a vulnerability that would have allowed a view key holder to burn funds
17:47:38 -endogenic> fwiw it is customary, every time someone says lelantus, to belt out the word as if it is a magical incantation
17:47:43 -wfaressuissia> Was it always the case that any cryptography update had final stage in form of binary predicate (safe / unsafe) implemented by security audit / paid peer review ?
17:47:52 -sgp[m]> this is being remedied
17:48:14 -UkoeHB> noizecore[m]: probably no closer than last week. I think Triptych is considered a fall-back if Seraphis/Spark fall through somehow.
17:48:36 -sgp[m]> agreed more or less 👍️
17:48:45 -UkoeHB> wfaressuissia: only since bulletproofs/CLSAG/bp+ I think
17:48:47 -ArticMine> I would agree with UkoeHB
17:49:14 -rbrunner> "allowed a view key holder to burn funds" huh?
17:49:17 -sethsimmons> UkoeHB: Agreed
17:49:20 -ArticMine> Sorry I got confused o nthe time
17:49:23 -wfaressuissia> Also does successfully passed audit / paid review for Seraphis / -any other decen. anon. paym. system> implementation is the only requirement to use it for monero ?
17:49:32 -gingeropolous> wfaressuissia, not in the earliest days. i forget if ringct went through that kind of gauntlet.
17:49:39 -wfaressuissia> s/does//
17:49:44 -sgp[m]> wfaressuissia[m]: no not always, RingCT originally was not audited (which ended up being really bad)
17:49:58 -sgp[m]> and then we ended up being lucky
17:50:01 -UkoeHB> rbrunner: yeah the key image contained only view key material, so a view key holder could make a malicious output to burn funds found in the view-only wallet
17:50:29 -rbrunner> Ugh ... thanks for the info
17:50:38 -noizecore[m]> UkoeHB: yeah i picked that up, Seraphis would be more beneficial for tx-chaining right?
17:51:03 -UkoeHB> noizecore[m]: yes, depending on design decisions (and assuming no issues are found)
17:51:04 -sgp[m]> it definitely sucks but it can be addressed luckily, and it's good it was caught so early
17:51:20 -gingeropolous> wfaressuissia, i wouldn't say thats the only requirement
17:51:53 -noizecore[m]> whats the latest on BP+?
17:51:59 -UkoeHB> > Also does successfully passed audit / paid review for Seraphis / -any other decen. anon. paym. system> implementation is the only requirement to use it for monero ?
17:51:59 -UkoeHB> There are also: utility, efficiency/size cost
17:52:16 -ArticMine> Do we have any figures?
17:52:18 -gingeropolous> and apparently multisignature happiness
17:52:34 -rbrunner> Exactly 🙂
17:52:38 -UkoeHB> noizecore[m]: pretty sure it's audited and waiting to be plugged in
17:53:10 -carrington[m]> BP+ is implemented, doubly audited and live on Wownero
17:53:12 -UkoeHB> ArticMine: not yet, still a lot of work on my end to get perf mock ups how I want them
17:53:17 -rottenstonks> ye, bp+ is ready to be rolled.
17:53:20 -carrington[m]> Last I checked
17:53:22 -rottenstonks> has been ready for a good while.
17:53:45 -noizecore[m]> so whats the next step? are we still bundling it with the next protocol upgrade?
17:53:50 -rottenstonks> ye, wownero has had bp+ for months...
17:53:52 -sgp[m]> ArticMine: still early for real numbers to compare apples:apples
17:54:01 -noizecore[m]> from what I understand Seraphis/LS are still a while off
17:54:43 -UkoeHB> is there an upcoming dev meeting to discuss bp+ planning?
17:54:43 -sgp_[m]> @r4v3r23:matrix.org: that's more of a dev question
17:54:48 -rottenstonks> noizecore[m]: no. there'll be a dev meeting to decide if we have a slight ring size increase, bp+ and whatever else, while we switch off to triptych, or lelantus and seraphis.
17:55:00 -rottenstonks> UkoeHB: aye, there is.
17:55:01 -noizecore[m]> UkoeHB: +1
17:55:37 -rottenstonks> or was... not seeing the issue on meta now. smh.
17:55:52 -UkoeHB> ok meeting is reaching the 1hr mark; should be punt the last agenda item (6. MRL META: Active recruitment of technical talent, MRL structure) to next week?
17:56:26 -Rucknium[m]> UkoeHB: I think that's fine. And yes, let's do same time next week
17:57:24 -rottenstonks> k thx, see ya next week. bai.
17:57:35 -UkoeHB> thanks for the meeting everyone
17:58:26 -gingeropolous> thanks all!
