12:14:08 <UkoeHB> reminder: meeting in 4.75hr (1700 UTC) https://github.com/monero-project/meta/issues/611
16:49:48 <gingeropolous> meetings like kinda soon right?
16:50:28 <sethsimmons> 10min in theory :)
16:51:40 <asdf234[m]> >.>
16:51:48 <asdf234[m]> >>.>
16:51:57 <asdf234[m]> hello!
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!
18:00:51 <gingeropolous> interesting topic re: whether enforced ring member selection method will inadvertently lock in things and prevent future mods when necessary
18:01:23 <gingeropolous> i mean, in theory, couldn't future mods be hardforked in?
18:01:50 <Rucknium[m]> gingeropolous: Yes, they could. That's why I think it's not a huge issue.
18:02:46 <Rucknium[m]> I have also been theorizing on a continually-updating distribution for the mixin selection algorithm, automated in consensus rules.
18:02:58 <gingeropolous> if i read UkoeHB 's point correctly, i think the concern is that it would put the core maintainers in a precarious position? 
18:03:12 <UkoeHB> > i mean, in theory, couldn't future mods be hardforked in?
18:03:12 <UkoeHB> The point is that, in the long run, hard forks will become harder to pull off.
18:03:26 <gingeropolous> indeed
18:03:40 <jberman> I think it's an understandable debate over whether or not the decoy selection algo should be tied to hard forks
18:03:50 <wfaressuissia> How much spam txs would be enough in order to abuse it ?
18:04:11 <wfaressuissia> s/much/many/
18:04:26 <UkoeHB> abuse what?
18:04:38 <gingeropolous> one fun thought i had somewhere a while ago was that we could somehow allow miners to to adjust consensus using the language of randomx
18:05:00 <gingeropolous> it puts consensus in the hands of the miners.. but .... yah know
18:05:25 <UkoeHB> somehow?
18:05:39 <Rucknium[m]> gingeropolous: randomx is a programming language? I have a lot to learn...
18:05:43 <asdf234[m]> wfaressuissia[m]: This would probably be more an issue of % of tx rather than a set quantity no?
18:05:59 <gingeropolous> yeah. in the block header
18:06:21 <gingeropolous> kinda soft forky like bitcoin
18:07:09 <gingeropolous> consensus does what the code in the binary says, and then checks what the current majority of some window of block headers says to do
18:07:43 <Rucknium[m]> So that I guess was part of my idea to continually update the distribution for the mixin selection algorithm. Have it at the consensus level, but specify the specific parameters in the block header. Then the block header conducts the "orchestra" of all the wlalet software. The wallet software follows what's in the block header, with some margin-of-error wiggle room.
18:07:49 <gingeropolous> well not soft forky at all, sorry.
18:08:22 <endogenic> i kinda dig it 
18:08:27 <gingeropolous> randomx is sorta kinda a programming language. 
18:08:30 <endogenic> wonder if it has any fingerprintability concerns
18:08:45 <Rucknium[m]> ^ This is very long-term stuff. My immediate work is to do a much more limited improvement
18:08:49 <jberman> A continually updating distribution doesn't necessarily need to be enforced by consensus
18:09:06 <Rucknium[m]> jberman: That is also true.
18:09:14 <gingeropolous> i think. hyc could slap some sense into me
18:09:22 <wfaressuissia> How many decoys can be marked as fake with confidence `C` by attacker with `A` amount of XMR spent on spam txs ?
18:09:43 <wfaressuissia> Your work is going to reduce the above number in the worst case or on average, right ?
18:09:47 <wfaressuissia> rucknium[m]
18:09:51 <endogenic> wfaressuissia: doesnt that depend on fees?
18:09:56 <UkoeHB> I think block header voting on consensus rules can cause network instability (i.e. arbitrary forking), since there is no trust graph to steer nodes.
18:10:17 <Rucknium[m]> Or, you could force, by consensus, miners to put the necessary info in the block headers to conduct the orchestra,  but the individual "players", i.e. wallet software, would not be obligated to follow the "conductor".
18:10:19 <endogenic> that sounds correct UkoeHB 
18:10:41 <endogenic> but isn't it following the same dynamics as PoW?
18:10:47 <UkoeHB> It's possible in something like Stellar, but those networks are way different from PoW.
18:11:18 <endogenic> guess you still need to determine which is the leading params
18:11:21 <Rucknium[m]> My idea on continually updating the mixin selection algorithm wouldn't rely on volitional "voting", but would be a formula baked into consensus
18:11:23 <endogenic> ic
18:11:40 <endogenic> Rucknium[m]: what formula, if you know yet?
18:12:07 <Rucknium[m]> wfaressuissia[m]: I am really not a good person to comment on this. Others would be better, I think. I will comment below, but it could be wrong:
18:12:26 <Rucknium[m]> endogenic: nonparametric density estimation, broadly
18:12:29 <wfaressuissia> min fee can't be controlled by attacker and dictated by code currently
18:13:46 <wfaressuissia> Also question, if fee goes to +inf, then that `How many decoys ...` monotonically decreasing or there will be extremum and then it will increase?
18:13:49 <wfaressuissia> s/fee/base fee/
18:13:53 <Rucknium[m]> So, on average, given that the ring sizes are 11, a total de-anonymizing FloodXMR "strike" would imply an increase to the tx volume of about 1,000%. That's based on my limited understanding
18:14:38 <Rucknium[m]> The fact that the volume only raised by 100% makes me think that it was not a truly malicious actor. Or at least a malicious actor would have only been "testing" and not launching a full attack.
18:15:00 <wfaressuissia> 10x ?
18:15:10 <UkoeHB> > then that `How many decoys ...` monotonically decreasing or there will be extremum and then it will increase?
18:15:10 <UkoeHB> Why would fees rising affect decoys? Not sure what you mean
18:15:24 <Rucknium[m]> Yeah. Attacker controls 90% of all outputs
18:16:22 <UkoeHB> Rucknium[m]: with fee algo it would take 1yr to increase block size big enough to allow 90% malicious (ceteris paribus)
18:16:32 <carrington[m]> Seth For Privacy   I have posted an unamended agenda for the next meeting if you would like to use it for the channel topic
18:16:32 <carrington[m]> https://github.com/monero-project/meta/issues/613
18:16:32 <carrington[m]> https://forum.monero.space/d/114-monero-research-lab-meeting-wed-29-september-2021-at-1700-utc
18:16:35 <UkoeHB> sorry block size algo*
18:16:56 <Rucknium[m]> UkoeHB: The current fee algo? or one proposed?
18:17:19 <wfaressuissia> UkoeHB, block size is 60KB on overage currently, so 80% is free for spam
18:17:26 <UkoeHB> one proposed, existing is even slower growth
18:17:30 <carrington[m]> Not sure if the agenda needs changing as similar topics will be discussed, but I will add some links shared during the meeting for easy organization
18:17:37 <Rucknium[m]> The entity was able to increase the tx volume by about 100% in just a day.
18:18:08 <UkoeHB> wfaressuissia: that's true, I meant in the case of honest volume filling the penalty free zone
18:18:51 <UkoeHB> carrington[m]: I think MRL Meta can be moved to the top, since it has been punted twice
18:19:45 <UkoeHB> Everything about spam is in the context of the min penalty free zone - no bets are made if honest volume is low.
18:20:08 <Rucknium[m]> I would also support moving it up in the list. Doesn't necessarily have to be at the top. Maybe the middle would be fine.
18:20:19 <wfaressuissia> From economic perspective, after some point number of non-spam related txs may drop non-linearly with base-fee increase. It will make spam attack even easier
18:20:57 <UkoeHB> That's a good point
18:21:46 <wfaressuissia> Any exact math model with numbers will be 100x more useful than any text
18:22:18 <wfaressuissia> base fee only discriminate users, but doesn't solve problem with decoys
18:22:39 <Rucknium[m]> I believe UkoeHB  will kill me if I try to analyze economic behavior with math, so no-go on that one, wfaressuissia[m]  :P
18:23:36 <UkoeHB> Just characterize it as engineering approximation, as it should be.
18:24:33 <Rucknium[m]> Any way you like it ;)
18:25:05 <wfaressuissia> Do you have any math models that shows how some privacy related metrics for decoys depends on other parameters (ring size, ...) ?
18:27:12 <Rucknium[m]> If your question is directed at me, I suppose an answer is yes, but they are confidential at this time.
18:31:34 <wfaressuissia> How long will it be private ? Are you sure that isn't public knowledge already for someone ?
18:34:08 <Rucknium[m]> I don't know. It is sort of in the Vulnerability Response Process. I don't really understand well how VRPs work.
18:34:57 <wfaressuissia> "[4] Validating the correct algo ..." Currently tx can use decoys from arbitrary (since the last hardfork) prefix of blockchain and can be submitted later. Are you going to test distribution for decoys at consensus without adding any new restrictions for tx generation ?
18:36:17 <UkoeHB> wfaressuissia: one way around that is to define a ‘distribution upper bound’ for all your decoys, so tx submission timing is divorced from decoys
18:37:32 <wfaressuissia> There are too much freedom for unorganized users that can be abused by single attacker in order to mark more fake decoys
18:37:37 <Rucknium[m]> wfaressuissia[m]: Good question. I discussed this on Reddit before. I'll see if I can find the link. If the contunually-updating mixin selection algorithm was enforced by consensus, then people would not be able to construct a tx, wait months, and then broadcast later, probably. But there's not a huge usecase for holding onto unbroadcasted txs for weeks or months.
18:37:46 <wfaressuissia> Are you sure that decoy model with less than full UTXO is fixable at all ?
18:38:04 <Rucknium[m]> wfaressuissia[m]: My view is "no"
18:38:19 <wfaressuissia> s/full UTXO/full set of UTXO/
18:38:33 <Rucknium[m]> But doing something different would be a radical departure
18:39:06 <jberman> wfaressuissia: poc for modifying tx construction such that it would also be guaranteed to match the distribution: https://github.com/monero-project/research-lab/issues/86#issuecomment-921805298
18:39:40 <jberman> using the current gamma distribution/selection algo equivalent
18:41:21 <wfaressuissia> I can't validate that code without any math model with privacy related metrics. There are too many things to consider at once since privacy is a property of whole system
18:42:04 <jberman> ok
18:43:01 <Rucknium[m]> wfaressuissia[m]: If you want to join the effort to improve some of the shortcomings highlighted here, I think that would be great:
18:43:01 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/86
18:43:30 <Rucknium[m]> See also: https://www.sciendo.com/article/10.1515/popets-2018-0025
18:44:42 <jberman> I was just answering this question: "Are you going to test distribution for decoys at consensus without adding any new restrictions for tx generation ?"