I am running the MRL meeting today at 17 UTC

what time is it now?

3am

somewhere in the world

(it's 4:04pm UTC)

.time

15 minutes

.time

MRL meeting time

1. Greetings

hey

Hi

hi all

hello everyone

2. Roundtable

Sarang is not present for this meeting today, but he has been working on coordinating the CLSAG audit for final release

Does anyone else have an update to share?

anyone following quantum computing,

"Following this roughly 18-month period, NIST will plan to release the initial standard for quantum-resistant cryptography in 2022."

Ooh interesting. We’re now digging through a vast pq-crypto landscape to find Monero compatible solutions leveraging Lattice Based Cryptography, Multivariate cryptography, Hash-Based Cryptography, Supersingular elliptic curve isogeny cryptography, or Quantum Key Cryptography. Will examine the NIST work as well.

Lattice-based SALRS and the MatRiCT are of particular interest so far, but we’re still executing a broad search.

There's a ton of pq-hard problems, though the vast majority are too unwieldy for implementation at the moment.

5 of the 7 candidates are lattice-based

decent overview medium.com/asecuritysite-when-bob-m…ttice-bake-in-the-lead-dafc23ecde20

Thanks for sharing these great resources hyc

I just skimmed that overview, nice stuff

any other roundtable updates?

we can then move on to 3. Questions

I got a question from Reddit: when is Monero going to change its ringsize? It will be going on two quick years with ringsize 11

I'm not aware of a significant reason to increase before something like Triptych

yeah, haven't seen any reason to rush

faster chain verification > marginal privacy improvement IMO

agree

selsta hyc: separating coinbase and dropping the ringsize to 1 or 3 for those tx will speed up a bit :p

only from that point on, though

can’t comment on that

not historically

and, it's like key sizes - sure, bigger keys are stronger, but there's no reason to use a bigger key than necessary

what is the general sentiment about whether to implement bulletproofs+?

My question with coinbase is why not just mix coinbase with coinbase. Then there is no hard fork required

ArticMine: requires hard fork to enforce

and non coinbase with non coinbase

sgp_: it would be a soft fork

you're tightening the existing rules

my impression of BP+ is it's probably a good idea, but I'd like to see some formal peer review finished first

wallets can do that now, but it would be relatively simple to identify which wallets are using that and which aren't

sure, soft fork could be possible but I guess why bother

also we need the hardfork if we want to shrink coinbase ringsize

I'm for BP+. If sarang gets a python implementation, I could do the C++, if he doesn't do it directly.

Why shrink coinbase ringsize?

if you mix coinbase only with coinbase is there any reason to shrink the ringsize?

I'm assuming it's not a huge change from our current code. If it is, I might change my mind.

hyc: coinbase outputs are quite toxic with all the public pool data

from my convs with sarang, sounds like BP+ should not be a big change

sgp_: which sounds like all the more reason to leave them the same ringsize as others.

<sgp_> hyc: coinbase outputs are quite toxic with all the public pool data <--- So why shrink the ring size then ?

did you both read my github issue about it?

link

last time I looked, 90% of coinbase outputs were attributable to specific pools. ringsize 11 can't handle a 90% scenario

I know but what I am saying is mix only with other ringsize outputs

coinbase*

ArticMine: I agree and support the idea of separating the two

We however have the option to configure the ringsizes separately if we want

luigi1111 voices support for doing this

*voiced

I will comment on the issue

ty

so if coinbase only mixes with coinbase, and ringsize 11 is inadequate, why drop down to size 3 or 1?

Options are:

1. Drop the coinbase ringsize to 1 or 3 for efficiency. Mostly write off coinbase outputs as a lost cause.

2. Keep it the same

3. Increase it knowing that coinbase outputs are a deducible bloodbath if we really feel that we need to protect coinbase outputs. It will cost us.

because it's a waste of blockchain space

hyc: from the issue linked above

I see a fair amount of consensus on segregating the coinbase outputs

How we then treat them can be the subject for further discussion

I will move with mixing coinbase with coinbase and non coinbase with non coinbase ASAP

not sure what the significance is. so 90% of coinbase outs can be attributed to specific pools. Then pools must split them to payout to miners

to get an idea of cost, in a 90% compromised scenario, and to protect 99% of rings with at least 1 non-compromised output, we need ringsize 45

sgp_ 's point is very valid

you can see why I don't want normal transactions to use these toxic decoys as non-convincing inputs

Yes

that's more a question of how many outputs are miner vs normal usage

what is that, about 72 transactions/day spending coinbase outputs?

*720

My proposal addresses the main issue of contamination normal outputs

but it seems clear to me that if you are splitting miner txs into their own pool, then they should just not mix at all

That depends on the ring size

greater efficiency for ~720 rings a day (on average) seems non-trivial

not huge either

shouldn't be that hard to quantify if you have some daily tx stats

gets to be insignificant as adoption increases

hyc: yeah, it's pretty constant regardless of adoption

If we can reach consensus on the treatment of the separated coinbase transactions before the next HF great

I hope so (not the Oct one obviously)

Otherwise I say go with ring 11 for the coinbase outputs

WHat I do not support is keeping the contamination of regular outputs while we decide

ArticMine: wallet change?

That is by far the simplest

hmm, that scares me a bit. wallets do weird stuff

but the specification has to be widely known

It is the same issue with fees

I mostly disagree and think status quo is status quo until there is a coherent plan for change

Making the specification widely know can address the bulk of the issue

we are wasting some space here, not dealing with something catastrophic

If there is consensus on part of the change, but not the rest, why hold up the part that has consensus?

you know I want to separate the rings more than anybody (save space and protect users), yet this non-consensus change scares me

One can enforce the coinbase with coinbase mix as consensus

but keep the mixing at 11 if there is not agreement on the correct mixing

all: please comment on that Github issue if you haven't already

anything else on this topic or any other questions?

4. Action items

sarang and I will put out the CLSAG audit report, hopefully in the next few days. It needs to go out

just waiting on OSTIF

everyone else?

as a part of the Monero Community Workgroup resources, I will start pushing a kanban board to keep track of tasks more. MRL is welcome to use it or not, but keep an eye out for that

if there is nothing else, we can conclude the meeting

Next meeting a week from now. Same bat time, same bat channel

Thanks for attending!

Thanks

Sorry, got pulled into a different meeting briefly.

Hmm, if we implement coinbase stuff in core wallet but not consensus, that does create a nice window for Noncesense to leverage those fingerprints to study use of core vs non-core software :smiling_imp:

Maybe better topic for -lounge, but I heard of an interesting token economic scheme used by Harmony One

441M tokens = emission + fees

If fees are low, emission is high to sustain security. Once fees become significant enough to secure the chain, emission decreases.

*It is not perfect!!* I'm always skeptical of constants that are hardcoded long in advance (like 441M ONE/yr or 0.6 XMR/block) and the miners could be incentivized to pull some shenanigans with high-fee txns to suppress emissions.

But, the angle is interesting, and gave me something to think about.

s/441M tokens/441M tokens per year

honestly the coinbase selection thing *feels* good and it makes sense at an immediate level, which makes me suspicious of it

i don't know what I'd need to quell that suspicion. i mean, at the end of the day, it could be done in wallets, so any 3rd party wallet out there could go ahead and make these improvements

there are various kick the can options... one is bumping from 11 to 14, so offset these useless ring members

the other is to flag the coinbase ring members when the CLI shows you the .... datagram? timeline of ring members being used in your tx

so if you were so compelled you could craft your transaction with no coinbase ringmembers

but if we even think that some users would do that to increase the efficacy of their ring sig construction, then it probably should be default

then again, we've had these situations before... we *knew* for a long time that non uniform mixin levels was flawed, yet that sorta got punted down the lane for whatever reason

we also knew that allowing 0 mixin level txs was flawed, and yet that stuck around for a good while

so my point is that perhaps these gut feeling solutions that seem to good to be true are just fine.

don't mind me, just talking in circles over here

Sgp_ I don't think the benefits of dropping the coinbase ring size are worth it. Even if inefficient, there's something nice about consistency

I can see a 'false sense of security' perspective, and low ring sizes being a prompt for the users to recognize that

i dunno. it kinda makes sense to treat them differently. they are indeed different.

Sure, I'm for coinbase/coinbase

They're treated differently, but the consistent ring size is nice. Less gotchas

'our ring sizes are 11 except for coinbase txes which are 3' is unwieldy

And we gain nothing other than a public signal that the txes are insecure (and a negligible bit of space)

well not making it public is just hoping to pull the wool over the eyes or whatever

We can be vocal about the drawbacks

Making a visible signal on chain has no precedent

How much space is gained by moving from 11 to 3 ?

We would have to test. Not huge

I'm guessing "noticeable but still quite small"

I'm surprised Snipa isn't here pushing for smaller coinbase ringsizes to save on pool tx fees :p

Because this is not #monero-lobbying.

you guys all seen this? eprint.iacr.org/2020/688.pdf

just saw it in last paragraph of this post bitcointalk.org/index.php?topic=5090272.msg54897029#msg54897029

This means that we can set mixins at a level from up to 1000, keeping the reasonable size and processing speed of transactions.