16:01:22 <m-relay> <r​ucknium:monero.social> MRL meeting here in one hour.
17:00:37 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/915
17:00:45 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:58 <m-relay> <v​tnerd:monero.social> Hi
17:03:01 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:23 <rbrunner> Hello
17:03:34 <m-relay> <v​tnerd:monero.social> Still on subaddresss (unit tests). It's basically done, minus at least one outstanding bug
17:04:30 <m-relay> <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: https://github.com/monero-project/research-lab/issues/59#issuecomment-1783237506
17:05:33 <m-relay> <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.
17:05:49 <m-relay> <j​effro256:monero.social> That’s way less than I would’ve guessed
17:05:52 <m-relay> <j​effro256:monero.social> Interesting
17:07:09 <m-relay> <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
17:08:48 <m-relay> <r​ucknium:monero.social> Some of the txs had some RingCt and non-RingCT rings. You can have both in a single tx
17:09:20 <m-relay> <j​effro256:monero.social> Do you have a count of total non-RingCT outputs and total number of non-RingCT inputs ?
17:10:15 <m-relay> <r​ucknium:monero.social> Total non-RingCT outputs that have every been produced? No, I don't have that right now.
17:10:38 <m-relay> <r​ucknium:monero.social> What do you mean by the second one?
17:11:05 <m-relay> <r​ucknium:monero.social> You mean total number of non-RCT rings that have ever existed?
17:12:30 <m-relay> <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
17:14:54 <m-relay> <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?
17:15:32 <m-relay> <r​ucknium:monero.social> Many of those outputs probably will never be spent. Lost keys, dust, etc.
17:16:11 <m-relay> <r​ucknium:monero.social> We are well into (3) Discussion. What do we want to discuss?
17:17:23 <m-relay> <j​effro256:monero.social> I posted a Jamtis proposal breakdown
17:17:25 <m-relay> <j​effro256:monero.social> https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4744307#gistcomment-4744307
17:17:46 <m-relay> <j​effro256:monero.social> Does anyone have questions or want to discuss pros/cons ?
17:19:34 <rbrunner> If I just take the column with the least "x", the winner is in the last one ...
17:19:47 <m-relay> <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
17:20:12 <m-relay> <v​tnerd:monero.social> as long as the address fits within a dns txt record for openalias, its not too bad
17:20:55 <rbrunner> I am a bit surprised about the minimal speed reductions. I vaguely remember some comments where you talked about much bigger (potential?) speed problems.
17:21:15 <rbrunner> Did I misunderstand?
17:21:20 <rbrunner> Or misremember?
17:22:11 <m-relay> <j​effro256:monero.social> No you remember correctly, but that’s a bandwidth thing for light wallets
17:22:35 <m-relay> <j​effro256:monero.social> The 0.4% difference is for full wallets
17:23:10 <rbrunner> I see. And how is that last column solution in this regard?
17:23:14 <m-relay> <j​effro256:monero.social> Light wallet *computation* is slowed down 100x
17:23:48 <m-relay> <j​effro256:monero.social> I should add that, even though I don’t think it’s a bottleneck
17:24:01 <rbrunner> Compute what?
17:24:37 <m-relay> <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
17:25:14 <m-relay> <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
17:25:36 <m-relay> <j​effro256:monero.social> We can do this by enforcing a different value for npbits
17:25:51 <m-relay> <j​effro256:monero.social> Basically CPU time needed for scanning
17:25:53 <m-relay> <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: https://github.com/Rucknium/misc-research/tree/main/Monero-Fungibility-Defect-Classifier/pd
17:26:40 <m-relay> <j​effro256:monero.social> No flexible view tags do NOT allow the wallet to choose view tag length unless they can skirt relay rules
17:27:43 <m-relay> <r​ucknium:monero.social> Then why does "Doesn't Need Recent Chaindata for VT constr.?" have a checkmark for flexible view tags?
17:27:45 <rbrunner> But we have to count on the community of Monero daemon runners to mostly update, for the scheme to work, right?
17:28:10 <rbrunner> Something similar like the tx_extra size restriction that was introduced that way
17:28:19 <m-relay> <j​effro256:monero.social> Because it would ostensibly be a constant value for a given set of rules
17:29:07 <m-relay> <j​effro256:monero.social> Yup, same with fees
17:30:46 <rbrunner> The slow, slow introduction of soft forks :)
17:30:52 <m-relay> <r​ucknium:monero.social> Zcash raised the fee for tx relay without a hard fork and it was a big UX problem, FWIW.
17:32:45 <rbrunner> Well, if things get really hard, I guess we could hardfork after all within a reasonable timeframe
17:33:02 <rbrunner> in that unlikely case
17:33:02 <m-relay> <j​effro256:monero.social> Well technically there is no soft forking involved since it’s only relay rules
17:33:06 <m-relay> <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.
17:34:03 <m-relay> <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
17:34:27 <m-relay> <r​ucknium:monero.social> Yes, that was it.
17:34:28 <m-relay> <j​effro256:monero.social> Yes
17:35:22 <m-relay> <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
17:35:57 <rbrunner> 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.
17:36:32 <m-relay> <j​effro256:monero.social> Wdym ?
17:37:00 <m-relay> <r​ucknium:monero.social> "We"....well, there are many nonstandard Monero wallet implementations
17:37:01 <rbrunner> Those Zcash problems in particular. I am not very surprised that many wallets and/or wallet users did not update intime
17:37:52 <rbrunner> Maybe we can mitigate by allowing the wallets to query the required length
17:38:03 <m-relay> <j​effro256:monero.social> Ohhhh yeah
17:38:06 <m-relay> <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.
17:38:44 <rbrunner> Indeed
17:39:28 <rbrunner> That "fee problem" should not have existed in the first place, for a sane cryptocurrency, if you ask me
17:39:39 <m-relay> <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
17:39:49 <m-relay> <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.
17:40:15 <rbrunner> But anyway, do we speculate that we may quickly establish new fee levels under some circumstances? If yes, which ones?
17:41:02 <rbrunner> (if we are already a bit off topic, talking about non-hardfork changes)
17:41:28 <m-relay> <r​ucknium:monero.social> I mentioned the Zcash fee problem since raising fees is similar to requiring a specific view tag length.
17:41:52 <rbrunner> Ok
17:42:08 <m-relay> <r​ucknium:monero.social> rbrunner: did you mean quickly establish new view tag lengths?
17:42:45 <rbrunner> No, I was just wondering whether it may be worth it to think a bit more about such relay rules updates
17:43:01 <rbrunner> because maybe beside view tag length fee changes could be already a second one
17:43:09 <rbrunner> and wondered whether I am correct there
17:43:43 <rbrunner> And "quick" comes in because, well, "cannot wait for a hardfork" maybe
17:43:44 <m-relay> <r​ucknium:monero.social> For example, if there were a spam incident that higher fees could defeat?
17:44:46 <rbrunner> 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
17:45:16 <rbrunner> The wallet may give the user an estimate that is way off, however
17:45:37 <m-relay> <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.
17:46:32 <m-relay> <r​ucknium:monero.social> You don't have to design around those 10%, but don't forget about it, either.
17:47:02 <rbrunner> Yes. I think we talk about problems with many aspects here.
17:47:35 <rbrunner> But anyway, if things are pretty quiet, as they are now for quite some time already, no view tag length changes, right?
17:48:11 <rbrunner> Or, we are talking not about the normal case, but about special situations.
17:50:45 <m-relay> <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
17:50:45 <m-relay> <j​effro256:monero.social> an’t keep up with their fraction of node requirements, then it could be adjusted through relay rule
17:51:14 <m-relay> <j​effro256:monero.social> But the idea is that most of the time they would be fixed size until the community manually changes it
17:52:03 <rbrunner> I guess the code is not much more complex, the code needed to implement that flexible length?
17:52:55 <m-relay> <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
17:53:37 <m-relay> <j​effro256:monero.social> But that also means that their anon set, according to one’s LWS, doesn’t increase with volume
17:54:13 <m-relay> <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.
17:54:47 <m-relay> <j​effro256:monero.social> That’s definitely one of the upsides of flexible view tags: implementation is much easier than dynamic
17:55:31 <m-relay> <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.
17:55:40 <rbrunner> I think dynamic has a lot of edge cases to consider, especially around the time of the dynamic change
17:56:26 <m-relay> <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
17:57:02 <rbrunner> 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
18:00:15 <m-relay> <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
18:01:56 <rbrunner> 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
18:02:14 <rbrunner> in complexity, time needed to implement, and resource requirements in general
18:02:27 <rbrunner> which I think is almost achieved
18:02:30 <rbrunner> IMHO
18:02:51 <m-relay> <r​ucknium:monero.social> Do a grep search for "why does syncing take so long" on all Monero support forums. :P
18:03:13 <rbrunner> Yeah, those people will get shiny new LWs :)
18:03:32 <rbrunner> Without any strong drawbacks
18:04:45 <m-relay> <r​ucknium:monero.social> We are past the hour. This conversation will continue :)
18:11:08 <m-relay> <j​effro256:monero.social> I’ll update the post with the clarifications here thanks so much y’all
21:19:32 <Lyza> ww
21:19:34 <Lyza> weir