<r​ucknium:monero.social> MRL meeting here in one hour.

<r​ucknium:monero.social> Meeting time! monero-project/meta #915

<r​ucknium:monero.social> 1) Greetings

<v​tnerd:monero.social> Hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

Hello

<v​tnerd:monero.social> Still on subaddresss (unit tests). It's basically done, minus at least one outstanding bug

<r​ucknium:monero.social> me: I counted the non-RingCT rings and transactions since the August 2023 hard fork. About 0.005% of txs had at least one non-RingCT ring: monero-project/research-lab #59#issuecomment-1783237506

<r​ucknium:monero.social> ^ This matters because we want to decide whether to allow non-RinCT outputs to be put in rings with RingCT outputs in the Seraphis upgrade proposal.

<j​effro256:monero.social> That’s way less than I would’ve guessed

<j​effro256:monero.social> Interesting

<r​ucknium:monero.social> Except in the unmixable edge case, users haven't been able to produce non-RingCT outputs for about 4 years IIRC. It makes sense to me that there are few users spending very old outputs

<r​ucknium:monero.social> Some of the txs had some RingCt and non-RingCT rings. You can have both in a single tx

<j​effro256:monero.social> Do you have a count of total non-RingCT outputs and total number of non-RingCT inputs ?

<r​ucknium:monero.social> Total non-RingCT outputs that have every been produced? No, I don't have that right now.

<r​ucknium:monero.social> What do you mean by the second one?

<r​ucknium:monero.social> You mean total number of non-RCT rings that have ever existed?

<j​effro256:monero.social> If we knew 1) the total number of non-RingCT outputs ever produced and 2) the total number of non-RingCT input rings ever used, then we could get a rough estimate of what percentage of non-RingCT outputs are unspent

<r​ucknium:monero.social> Yes. You could probably break it down further by non-RCT amount. It's an interesting question, but it would take some time to code it up. How important is it to the GitHub issue discussion?

<r​ucknium:monero.social> Many of those outputs probably will never be spent. Lost keys, dust, etc.

<r​ucknium:monero.social> We are well into (3) Discussion. What do we want to discuss?

<j​effro256:monero.social> I posted a Jamtis proposal breakdown

<j​effro256:monero.social> gist.github.com/tevador/50160d160d2…ment_id=4744307#gistcomment-4744307

<j​effro256:monero.social> Does anyone have questions or want to discuss pros/cons ?

If I just take the column with the least "x", the winner is in the last one ...

<j​effro256:monero.social> It’s not that important but would add an extra layer of depth to the discussion of if its worth it to change. Honestly I could code this up myself tho

<v​tnerd:monero.social> as long as the address fits within a dns txt record for openalias, its not too bad

I am a bit surprised about the minimal speed reductions. I vaguely remember some comments where you talked about much bigger (potential?) speed problems.

Did I misunderstand?

Or misremember?

<j​effro256:monero.social> No you remember correctly, but that’s a bandwidth thing for light wallets

<j​effro256:monero.social> The 0.4% difference is for full wallets

I see. And how is that last column solution in this regard?

<j​effro256:monero.social> Light wallet *computation* is slowed down 100x

<j​effro256:monero.social> I should add that, even though I don’t think it’s a bottleneck

Compute what?

<j​effro256:monero.social> So the last column “flexible” VTs allows the community to adjust the “match rate” for LW scanning as light wallet users require

<j​effro256:monero.social> So it doesn’t make anything *faster* but allows us to manually control the bandwidth and computation requirements for light wallets if it gets out of hand

<j​effro256:monero.social> We can do this by enforcing a different value for npbits

<j​effro256:monero.social> Basically CPU time needed for scanning

<r​ucknium:monero.social> Something I can contribute is the potential privacy impact of flexible vs dynamic view tags. AFAIK, flexible view tag length allows the wallet to choose length, which can produce transaction non-uniformity on chain. My discussion note on fungibility defects can tell you how big the privacy impact could be: github.com/Rucknium/misc-research/t…ro-Fungibility-Defect-Classifier/pd

<j​effro256:monero.social> No flexible view tags do NOT allow the wallet to choose view tag length unless they can skirt relay rules

<r​ucknium:monero.social> Then why does "Doesn't Need Recent Chaindata for VT constr.?" have a checkmark for flexible view tags?

But we have to count on the community of Monero daemon runners to mostly update, for the scheme to work, right?

Something similar like the tx_extra size restriction that was introduced that way

<j​effro256:monero.social> Because it would ostensibly be a constant value for a given set of rules

<j​effro256:monero.social> Yup, same with fees

The slow, slow introduction of soft forks :)

<r​ucknium:monero.social> Zcash raised the fee for tx relay without a hard fork and it was a big UX problem, FWIW.

Well, if things get really hard, I guess we could hardfork after all within a reasonable timeframe

in that unlikely case

<j​effro256:monero.social> Well technically there is no soft forking involved since it’s only relay rules

<r​ucknium:monero.social> With flexible few tags, "Doesn't Need Recent Chaindata for VT constr.?" is "does not", but the wallets have to know what the nodes are requiring, still.

<j​effro256:monero.social> What was the UX problem? I assume there were wallets which didn’t update to the new rules and their transactions got dropped

<r​ucknium:monero.social> Yes, that was it.

<j​effro256:monero.social> Yes

<j​effro256:monero.social> FWIW I don’t foresee the length getting changed ls very often, only in cases where it becomes unweildy for a large section of LW users

Well, aren't we talking about a coin that needs months to address even very serious problems, quite in general? I hope we could do better.

<j​effro256:monero.social> Wdym ?

<r​ucknium:monero.social> "We"....well, there are many nonstandard Monero wallet implementations

Those Zcash problems in particular. I am not very surprised that many wallets and/or wallet users did not update intime

Maybe we can mitigate by allowing the wallets to query the required length

<j​effro256:monero.social> Ohhhh yeah

<r​ucknium:monero.social> The Zcash problem was foreseeable. They should have implemented the fee changes at a hard fork. But once they decided to have it as a node relay rule, it's hard to fix the problem.

Indeed

That "fee problem" should not have existed in the first place, for a sane cryptocurrency, if you ask me

<j​effro256:monero.social> That’s not a bad idea… as long as it’s cached and almost never changes then it shouldnt usually affect UX

<r​ucknium:monero.social> Zcash even has a small advantage: Their node software has an auto-shutoff period. Node runners have to update their nodes once every...3 months I think. So they could assume that nodes would update their relay rules. Many wallets didn't of course.

But anyway, do we speculate that we may quickly establish new fee levels under some circumstances? If yes, which ones?

(if we are already a bit off topic, talking about non-hardfork changes)

<r​ucknium:monero.social> I mentioned the Zcash fee problem since raising fees is similar to requiring a specific view tag length.

Ok

<r​ucknium:monero.social> rbrunner: did you mean quickly establish new view tag lengths?

No, I was just wondering whether it may be worth it to think a bit more about such relay rules updates

because maybe beside view tag length fee changes could be already a second one

and wondered whether I am correct there

And "quick" comes in because, well, "cannot wait for a hardfork" maybe

<r​ucknium:monero.social> For example, if there were a spam incident that higher fees could defeat?

Yeah, but I think we may be on the safe side here, because if I remember correctly the daemons tells the fee that is needed

The wallet may give the user an estimate that is way off, however

<r​ucknium:monero.social> Yes, but about 10% of transactions are produced by wallets that don't listen to the nodes. Or mis-hear the nodes....I dont know.

<r​ucknium:monero.social> You don't have to design around those 10%, but don't forget about it, either.

Yes. I think we talk about problems with many aspects here.

But anyway, if things are pretty quiet, as they are now for quite some time already, no view tag length changes, right?

Or, we are talking not about the normal case, but about special situations.

<j​effro256:monero.social> Yeah fixed-length view tags are great in that their privacy scales up with volume, and you compare your LW specs as a linear fraction of what the node requirements are. They only real downside is that they can’t adjust in special circumstances. That is what I aim with “flexible” view tags: they normally don’t change, but if there is a large outcry from LW users that they c<clipped messag

<j​effro256:monero.social> an’t keep up with their fraction of node requirements, then it could be adjusted through relay rule

<j​effro256:monero.social> But the idea is that most of the time they would be fixed size until the community manually changes it

I guess the code is not much more complex, the code needed to implement that flexible length?

<j​effro256:monero.social> Dynamic view tags, on the other hand, adjust dynamically to match a certain number of enotes per time period based on transaction volume. Which means that LW requirements will never have to increase ever

<j​effro256:monero.social> But that also means that their anon set, according to one’s LWS, doesn’t increase with volume

<r​ucknium:monero.social> I don't like the idea of an "outcry" triggering a change in tx relay rules, if the issue can be anticipated.

<j​effro256:monero.social> That’s definitely one of the upsides of flexible view tags: implementation is much easier than dynamic

<j​effro256:monero.social> Well just because the outcry doesn’t exists doesn’t mean you have to respond to it , but now you have the option.

I think dynamic has a lot of edge cases to consider, especially around the time of the dynamic change

<j​effro256:monero.social> The problem is that these performance / processing requirement are REALLY HARD to anticipate. @tevador and I spent weeks talking about this but at the end of the day it’s just speculation

There will probably be an outcry because something happened, and that "something" may well be unexpected. We would not care about the outcry, but about what happened

<j​effro256:monero.social> Yeah, the flexible step is probably smaller. The decision between flexible and dynamic honestly isn’t too important because we can switch back and forth between the two by changing relay rules, just like we would change flexible view tag size. The really important decision is whether we want to add the extra exchange key or not

I think you will be able to win people over for that if it can be shown that the thing "flies", that the necessary changes are reasonable all around

in complexity, time needed to implement, and resource requirements in general

which I think is almost achieved

IMHO

<r​ucknium:monero.social> Do a grep search for "why does syncing take so long" on all Monero support forums. :P

Yeah, those people will get shiny new LWs :)

Without any strong drawbacks

<r​ucknium:monero.social> We are past the hour. This conversation will continue :)

<j​effro256:monero.social> I’ll update the post with the clarifications here thanks so much y’all

ww

weir