reminder: meeting in 4.75hr (1700 UTC) monero-project/meta #611

meetings like kinda soon right?

10min in theory :)

>.>

>>.>

hello!

meeting time: monero-project/meta #611 I will take chair unless someone else steps up

1. greetings

hello

Hi

hi there

Hello

hello! here to watch

Hello

Howdy

Today we will skip updates in favor of agenda items.

2. Improvements to the mixin selection algorithm

Hello

Hi all

hi

waddap.

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

Work is proceeding apace

jberman has some updates on enforcement of the distribution at the consensus level I think

Reminder of 4 areas are:

1. Integer truncation in the wallet (e.g.: `3 / 2 = 1`)

2. Binning

3. Modifying the distribution estimator (@Rucknium spearheading this)

4. Validating correct algo used at consenus

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.

[1] Integer truncation is still out for review in PR 7798, nothing to update there

[2] Binning is still mostly relevant to discuss in context of what to do with timelocks, again

[3] Ruck's update clarifies what he's up to there

[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

I agree that [4] is going to be very tricky. It will need months of dedicated study.

[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).

AFAICT timelocks have no support, and could be removed without any major ecosystem effect.

^

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.

It would be helpful for people to look at the alternative solutions and express opinions/ideas (instead of silently agreeing).

I don't think there are any issues with deprecation there.

Seth For Privacy: jberman has written up some initial thoughts about ecosystem impact here:

I think the most interesting known use case for it is proof of unspent funds

Described there and in that discussion

Alternative solutions?

FWIW I removed unlock_time for all txes except coinbase and nothing broke.

You mean in a test branch of yours?

Yes (TF).

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.

Proof of balance does not use timelocks.

encryption option sounds like the best bet besides the increase in t size

how much bigger are we talking?

s/t/tx/

noizecore[m]: something like 25-50%

Just read the jberman details, still all for removal.

Right, people/Binance could use that proof of balance (get_reserve_proof) instead

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.

UkoeHB: and besides that it has a clear benefit over all other options yeah?

Not to mention the issues with binning etc.

It does leak private info though (ie, which outputs are yours IIRC).

Increased dev time and no real use case ATM.

it does? I haven't looked at it too closely

Though that could be mitigated. It uses 1-rings IIRC. Could be made to use 11-rings or whatever else.

The encrypted option would involve extra dev work AFAIK.

In fact, it could use huge rings since we don't really care that much about size or verification time.

My understanding is that, if needed, a timelock feature can probably be implemented on the client side.

(but I may be wrong ?).

So I don't see as crucial to put such a feature in the protocol.

s///

Anyway, for unlock_time, my preference is remove and add later if needed for L2 purposes or the like (and possibly with different semantics).

+1

moneromooo: Agreed!

I also prefer to remove. It is a legacy thing mainly used to lock coinbase outputs (probably added for that purpose originally).

Can coinbase outputs be locked another way?

What happens to the 60 block lock if unlock_time is removed?

UkoeHB: how would this affect UX?

hi all, sorry I'm late

You could keep it for them.

Or can it be used for just coinbase without effecting binning?

Just an implementation detail, not an issue sethsimmons

Ok, great :)

Just hardcode then?

noizecore[m]: it would simplify UX a bit, by removing some options

Ok, I think we can move on from timelocks, don't need to take up the whole time on it

jberman Rucknium[m] anything else to add about agenda item 2? Points we should put more attention on?

Summary: consensus continues to form strongly for removing and bringing back if desired

No, I am done with item 2

moneromooo: +1

jberman: ?

3. Analysis of July-Aug 2021 tx volume anomaly

isthmus:

According to my impression, we have produced overwhelming evidence that the tx volume anomaly was due to the actions of a single entity...

Furthermore, doing so was incredibly cheap if our calculations were correct.

isthmus seems not to be here right now, but myself jberman, carrington, and gingeropolous have helped

I think the results will be released within a day or two

👀 single entity?

But on every metric we looked at, the conclusion seems inescapabale.

I think the fee analysis has generally considered spam in the minimum penalty free zone of 300kB to be acceptable.

The conclusions are spooky and should motivate a network upgrade ASAP

approx how many transactions do you think we created this way?

"we" ?

lulz. prolly "were"

as in the monero network?

hehe, "were"

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)

what would make you think that

It could also be a malicious entity testing things out.

1) They did not try to hide their actions at all

2) The "flood" wasn't quite enough to seriously harm privacy

UkoeHB Yes, that is one possibility.

I'll wait for the writeup, but I have many other questions still

Me too

isthmus thinks that a hardfork, or whatever is needed, needs to come soon to fix the low fee issue.

yes .. this is important to discuss, but i dunno how productive this can be if the report isn't available for review etc.

"[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 ?

s/and can be verified//

People probably won't agree that we have a "low fee issue"

wfaressuissia[m]: That's earlier in the agenda, but what do you mean?

Fee increase + ruck and jbermans decoy selection work would go a long way to mitigating such an attack

A single tx can be like one tenth of one cent, right?

Would that made such a flood considerably more expensive already?

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.

we already have a proposal for the base fee increase

In general, bad decoy selection amplify efficiency of spam attack, but doesn't ideal decoy selection isn't a protection against spam attack

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"

s/doesn't//

and yeah it's definitely more complicated than base fee * txs, that's 1 thing floodxmr messed up in v1 of their paper

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.

yeah cheap in any case

well, that chain needs to be active for ring sigs to do their thing

*the chain

im just stating obvious things

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

> "[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 ?

I am also curious about this.

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.

UkoeHB: What do you mean by metrics?

Maths :)

so, whats the goal here? try and find ways to prevent flood attack? or mitigate the effect of flood attack?

he probably means, how to assess if a proposal for enforcing distribution is worth pursuing?

can't prevent really

Do you mean what criteria might be used to enforce the distribution used?

[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

We could go through the chain and identify blatantly incorrect rings as a % of all rings

How will you assess whether a given change is beneficial compared to what we have.

to me, prevention is fee based. mitigation is ringsize a bajillion and smarter ring member selection

(I assume that's what is meant by metrics)

openmonero is using a blatantly old implementation of the decoy selection algo that I believe can be fingerprinted

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.

I think we can identify openmonero tx's

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 ...

whoa, whoa. big if true. jberman

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.

rbrunner: the proposal for this upgrade was written and discussed before this attack

rbrunner: did you through MRL 70 yet?

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.

interesting UkoeHB

Only a cursory glance.

If we had binning we could have deterministic rings without the need for statistical tests, yes?

k.

That's my understanding of what a FloodXMR attack involves

That's my understanding carrington[m]

Well, maybe truly malicious entities can also fees that are quite a lot higher ...

okay there are a bunch of different overlapping topics right now being discussed at the same time

moneromooo: I want to get back to this

rbrunner: This is also true

sgp_: I think some ideas have already been floated. We don't have to enumerate all of them. It's an ongoing process.

short paper (2014) from MRL about floodXMR

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.

We can probably conclude this agenda item I guess? Summary is that anomaly analysis should motivate urgent work towards a network upgrade

ok let's get back on track

- [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)

- 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

- spam: a report is incoming from isthmus

4. Triptych vs. alternatives; any new questions/comments?

yes all sounds good koe

oh quick update just for visibility

UkoeHB: yes how close are we to a decision? is triptych more or less off the table?

on lelantus spark

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.

an outside researcher found a vulnerability that would have allowed a view key holder to burn funds

fwiw it is customary, every time someone says lelantus, to belt out the word as if it is a magical incantation

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 ?

this is being remedied

noizecore[m]: probably no closer than last week. I think Triptych is considered a fall-back if Seraphis/Spark fall through somehow.

agreed more or less 👍️

wfaressuissia: only since bulletproofs/CLSAG/bp+ I think

I would agree with UkoeHB

"allowed a view key holder to burn funds" huh?

UkoeHB: Agreed

Sorry I got confused o nthe time

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 ?

wfaressuissia, not in the earliest days. i forget if ringct went through that kind of gauntlet.

s/does//

wfaressuissia[m]: no not always, RingCT originally was not audited (which ended up being really bad)

and then we ended up being lucky

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

Ugh ... thanks for the info

UkoeHB: yeah i picked that up, Seraphis would be more beneficial for tx-chaining right?

noizecore[m]: yes, depending on design decisions (and assuming no issues are found)

it definitely sucks but it can be addressed luckily, and it's good it was caught so early

wfaressuissia, i wouldn't say thats the only requirement

whats the latest on BP+?

> 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 ?

There are also: utility, efficiency/size cost

Do we have any figures?

and apparently multisignature happiness

Exactly :)

noizecore[m]: pretty sure it's audited and waiting to be plugged in

BP+ is implemented, doubly audited and live on Wownero

ArticMine: not yet, still a lot of work on my end to get perf mock ups how I want them

ye, bp+ is ready to be rolled.

Last I checked

has been ready for a good while.

so whats the next step? are we still bundling it with the next protocol upgrade?

ye, wownero has had bp+ for months...

ArticMine: still early for real numbers to compare apples:apples

from what I understand Seraphis/LS are still a while off

is there an upcoming dev meeting to discuss bp+ planning?

@r4v3r23:matrix.org: that's more of a dev question

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.

UkoeHB: aye, there is.

UkoeHB: +1

or was... not seeing the issue on meta now. smh.

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?

UkoeHB: I think that's fine. And yes, let's do same time next week

k thx, see ya next week. bai.

thanks for the meeting everyone

thanks all!

interesting topic re: whether enforced ring member selection method will inadvertently lock in things and prevent future mods when necessary

i mean, in theory, couldn't future mods be hardforked in?

gingeropolous: Yes, they could. That's why I think it's not a huge issue.

I have also been theorizing on a continually-updating distribution for the mixin selection algorithm, automated in consensus rules.

if i read UkoeHB 's point correctly, i think the concern is that it would put the core maintainers in a precarious position?

> i mean, in theory, couldn't future mods be hardforked in?

The point is that, in the long run, hard forks will become harder to pull off.

indeed

I think it's an understandable debate over whether or not the decoy selection algo should be tied to hard forks

How much spam txs would be enough in order to abuse it ?

s/much/many/

abuse what?

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

it puts consensus in the hands of the miners.. but .... yah know

somehow?

gingeropolous: randomx is a programming language? I have a lot to learn...

wfaressuissia[m]: This would probably be more an issue of % of tx rather than a set quantity no?

yeah. in the block header

kinda soft forky like bitcoin

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

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.

well not soft forky at all, sorry.

i kinda dig it

randomx is sorta kinda a programming language.

wonder if it has any fingerprintability concerns

^ This is very long-term stuff. My immediate work is to do a much more limited improvement

A continually updating distribution doesn't necessarily need to be enforced by consensus

jberman: That is also true.

i think. hyc could slap some sense into me

How many decoys can be marked as fake with confidence `C` by attacker with `A` amount of XMR spent on spam txs ?

Your work is going to reduce the above number in the worst case or on average, right ?

rucknium[m]

wfaressuissia: doesnt that depend on fees?

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.

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".

that sounds correct UkoeHB

but isn't it following the same dynamics as PoW?

It's possible in something like Stellar, but those networks are way different from PoW.

guess you still need to determine which is the leading params

My idea on continually updating the mixin selection algorithm wouldn't rely on volitional "voting", but would be a formula baked into consensus

ic

Rucknium[m]: what formula, if you know yet?

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:

endogenic: nonparametric density estimation, broadly

min fee can't be controlled by attacker and dictated by code currently

Also question, if fee goes to +inf, then that `How many decoys ...` monotonically decreasing or there will be extremum and then it will increase?

s/fee/base fee/

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

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.

10x ?

> then that `How many decoys ...` monotonically decreasing or there will be extremum and then it will increase?

Why would fees rising affect decoys? Not sure what you mean

Yeah. Attacker controls 90% of all outputs

Rucknium[m]: with fee algo it would take 1yr to increase block size big enough to allow 90% malicious (ceteris paribus)

Seth For Privacy I have posted an unamended agenda for the next meeting if you would like to use it for the channel topic

sorry block size algo*

UkoeHB: The current fee algo? or one proposed?

UkoeHB, block size is 60KB on overage currently, so 80% is free for spam

one proposed, existing is even slower growth

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

The entity was able to increase the tx volume by about 100% in just a day.

wfaressuissia: that's true, I meant in the case of honest volume filling the penalty free zone

carrington[m]: I think MRL Meta can be moved to the top, since it has been punted twice

Everything about spam is in the context of the min penalty free zone - no bets are made if honest volume is low.

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.

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

That's a good point

Any exact math model with numbers will be 100x more useful than any text

base fee only discriminate users, but doesn't solve problem with decoys

I believe UkoeHB will kill me if I try to analyze economic behavior with math, so no-go on that one, wfaressuissia[m] :P

Just characterize it as engineering approximation, as it should be.

Any way you like it ;)

Do you have any math models that shows how some privacy related metrics for decoys depends on other parameters (ring size, ...) ?

If your question is directed at me, I suppose an answer is yes, but they are confidential at this time.

How long will it be private ? Are you sure that isn't public knowledge already for someone ?

I don't know. It is sort of in the Vulnerability Response Process. I don't really understand well how VRPs work.

"[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 ?

wfaressuissia: one way around that is to define a ‘distribution upper bound’ for all your decoys, so tx submission timing is divorced from decoys

There are too much freedom for unorganized users that can be abused by single attacker in order to mark more fake decoys

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.

Are you sure that decoy model with less than full UTXO is fixable at all ?

wfaressuissia[m]: My view is "no"

s/full UTXO/full set of UTXO/

But doing something different would be a radical departure

wfaressuissia: poc for modifying tx construction such that it would also be guaranteed to match the distribution: monero-project/research-lab #86#issuecomment-921805298

using the current gamma distribution/selection algo equivalent

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

ok

wfaressuissia[m]: If you want to join the effort to improve some of the shortcomings highlighted here, I think that would be great:

See also: sciendo.com/article/10.1515/popets-2018-0025

I was just answering this question: "Are you going to test distribution for decoys at consensus without adding any new restrictions for tx generation ?"