MRL meeting in this room in two hours

Meeting time! monero-project/meta #897

1) Greetings

Hi

Hello

<v​tnerd:monero.social> Hi

<m​urksombra:matrix.org> hi!

2) Updates. What is everyone working on?

<v​tnerd:monero.social> me: finished testing up P2P+SSL, and pushed a PR. Also working on subaddresses (more this week than last)

<v​tnerd:monero.social> cryptogrampy: made some good comments (on subaddresses+LWS) that I will address

I finished the draft of the discussion note: "Formula for Accuracy of Guessing Monero Real Spends Using Fungibility Defects" github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf

jeffro256 and I have been working on a proposal to change the Jamtis specs to improve the privacy for users of 3rd party scanners.

<m​urksombra:matrix.org> me: joined yesterday. Catching up with current developments and see where I can contribute.

m​urksombra: Welcome! Do you have a specific area you are interested in?

<v​tnerd:monero.social> tevador: where is this discussion taking place? I need to at least watch the discussion for LWS purposes

<m​urksombra:matrix.org> I can help from coffee to cryptography :)

The (incomplete, work in progress) proposal and discussion is here: gist.github.com/tevador/50160d160d2…ment_id=4692457#gistcomment-4692457

<m​urksombra:matrix.org> mostly cryptography I should say :)

You can never have enough cryptographers, it seems sometimes :)

Er, *too many

m​urksombra: Great. The main cryptography things happening are Seraphis/Jamtis and Full Chain Membership Proofs using Curve Trees

<m​urksombra:matrix.org> ack. will check.

<m​urksombra:matrix.org> but again, I can war multiple hats and contribute in other areas as well. Hardening, OPSec yadda yadda

3) Discussion. What do we want to discuss?

Maybe, as tevador is here, a question from me

tevador: Do you want to summarize the main points you want feedback for the changes to Jamtis specs?

Right, that was also my question :)

Where do we stand with that? Still fully open? Slowly converging towards an improved Jamtis?

OK. The proposal is to introduce "dynamic view tags", which adjust according to tx volume, plus to remove some privacy leaks from the current specs.

The current Jamtis spec leaks to the 3rd party scanner any outputs that have been received to a reused address and also outputs received to publicly known addresses.

Also the current spec has a fixed 8-bit view tag and some people noted that if tx volume increased dramatically, 3rd party scanners would become useless.

Or more likely would have to switch to a less private wallet tier.

I would predict that some 3rd party scanner services would implement just one static receive address, so the privacy improvements there are a good idea.

The proposal would increase address length from 196 to 244 characters, but that's still withing an acceptable range.

The dynamic view tag size will be determined by a formula in monerod's code that automatically adjusts so no software update needed when tx volume rises, right?

So the two view tags with different sizes, as already put into code by jeffro256, morphed into a single view tag, but with variable, adjusting size?

Yes, the view tag size adjusts automatically by using a formula based on the number of outputs in the last 100 000 blocks.

Addresses do not change when the view tag size changes, right? So an address would be valid both before and after adjustment?

No, only the view tag inside transactions changes.

It's meant to adjust to follow long-term tx volume.

100 000 blocks is also what the block size limit is based on

About 4 months

I will post more details later, but for example, between 2018 and 2023, the view tag would have grown from 4 bits to 6 bits (with a period of 7 bits during the spam attack last year).

The size is adjusted for 1 false positive per block on average.

What is "one false positive per block"?

Besides the outputs you own, the view tag will also match, on average, 1 output per block that you don't own.

A tx sent to somebody as "probably yours" but turning out not be such?

Over all tx receivers of the block, right?

Every wallet will calculate a different view tag for every output, but on average, everyone will see 1 false match per block.

This is done to hide your real outputs from the 3rd party scanner.

Ah, ok

Dynamic view tag size good to me on first hearing it :). The point of debate to the new changes will probably the "is more privacy for 3rd party scanning worth adding 48 characters to an address?" question.

The 3rd party scanner will send all matches to your wallet, so you have to scan only 720 outputs per day.

Is this a new idea? Making the view tags *less* precise?

I think so. View tags that are too precise would basically leak your outputs to the 3rd party scanner.

I mean was this already a consideration when we came up with the current 1-byte view tag? Maybe not

The difference is that whoever can calculate the current 8-bit tag can also fully recognize owned outputs. That changes with Jamtis.

Jamtis has one key that can only calculate view tags. Another key is used to actually calculate if the output key is yours.

I see

There are basically 3 different levels of "view only" wallet rather than just one level.

Does sound quite attractive, that dynamically sized view tag.

UkoeHB said in the Sept 11 No Wallet Left Behind meeting:

"Planning for users who need 2-byte filters in order to use monero is planning for users who cannot use monero AT ALL without a light wallet server, which is not a situation we should aim for. Local scanning is a first class citizen, and if a user can't local scan then they are out of our design space."

Is there general agreement on this point: "if a user can't local scan then they are out of our design space"?

The dynamic tag has a range 1-16 bits. The 16-bit size is probably unrealistic, would need around 65k outputs *per block*, but that's future-proofing I guess.

I think it's a bit hard to find the proper context of that opinion stated by UkoeHB

There was much back-and-forth discussion by him and jeffro256 about this

with a large numbers of different arguments

The benefit of the dynamic tag is that 1) Users of remote scanners get to keep some privacy. 2) Users of remote scanners only have to download about 200 KB per day. Basically instant sync.

You could argue in the extreme that currently a rarely used smartphone Monero wallet borders on unsusable, because of the long time to catch up without any third-party scanning support

E.g. don't use for a few months, wait hours until synced again

I don't think it will be hard to document it since it seems like a simple rule, but please document the formula/algorithm well if it's planned for implementation so "third party" wallets know what to do :)

Yes, our goal is to have a precise specification.

Including the times around switching bit size, which may be a bit tricky

because I know a lot of them don't know what to do with fees.

Well, maybe they are just lazy to implement it properly :)

Yes, we don't want the tag size to create anonymity puddles, so the size will be enforced by a relay rule.

which is a good segue into github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf

Wallets that cut corners and hardcode the size won't work.

I'll quote the main point from the abstract:

"Using basic probability concepts I develop a closed-form expression for the probability that the classifier correctly classifies a ring member as the real spend. This probability, the Positive Predictive Value (PPV) is a function of ring size, the probability that a user spends change in a ring, and the proportion of transaction outputs on the

blockchain that have the defect."

"For example, when these values are 16, 40%, and 5%, respectively, the probability that the classifier correctly classifies a ring member as the real spend is 31.7%, much higher than the 1/16 = 6.25% probability of randomly guessing between the 16 ring members."

Table 1 has a lot more possible value for probability of spending change and proportion of outputs with the defect. Table 2 does the same for ring size 128

I think this is a nice little contribution. For years there has been a worry about how much tx fungibility defects are affecting user privacy. Now we can put specific numbers on it.

Agree

If there is some tradeoff between requiring more transaction format strictness and some other goal, we can weigh the options with the estimated privacy benefits.

What's in the note isn't quite mathematical proofs of the formula, but it's pretty close. Assuming I didn't make an algebra mistake ;)

I wrote a Monte Carlo simulation, too, and it gives the same values (within epsilon) as the closed-form expression I developed.

Hopefully, these problems will disappear with full chain membership proofs.

Or at least be much less severe.

<m​urksombra:matrix.org> is this public?

Yes, much less severe. Only really rare defects would be a problem with full chain membership proofs.

m​urksombra: My discussion note? Yes: github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf

<m​urksombra:matrix.org> ty

Feel free to type any comments or questions about the discussion note here in the MRL channel. We're almost at the end of the hour, so let's end the meeting here.

<r​ucknium:monero.social> Sombra: Just saw that you meant the Monte Carlo simulation code, too. Here it is: github.com/Rucknium/misc-research/b…er/code/Monte-Carlo-PPV-estimator.R

seeing all this added complexity to make third party scanning workable makes me wish we'd just end it by killing view keys altogether (extreme) or at least focus on making the local / remote node experience faster and safer so fewer people feel the need for such services

like the fact that wallets put a *lot* of trust in whatever node they're connected to even when it's not marked trusted, while the GUI still connects to random, likely untrustworthy nodes in simple mode

<e​ndor00:matrix.org> The whole point of viewtags is to reduce the scanning load, because otherwise there is a lot of computation to be done for every tx output that shows up in every tx

<e​ndor00:matrix.org> And without viewkeys, you cut down on one of the fundamental privacy features of Monero

Without view tags, people will just use private viewkey for scanning (like MyMonero does), and that's even worse

And view tags are not only for third-party scanning. Scanning the blockchain yourself also profits from them, of course.

But yes, Jamtis and Seraphis are very complex beasts already, and Jamtis seems to grow a little more still now.

One can somehow wonder what's wrong with this universe that a private cryptocurrency needs such a crazy big machinery

Or maybe just nobody found the breakthrough yet ...

well, luckily, i have virtually converged the lws and full wallet code (private repo soon to make public) so it will be easy to switch over. previously the lws client was virtually behaving like a different currency's wallet. i will share the details "soon"... but really, mostly just the write up left

some big stuff

the lws code came from wallet2 originally so converging isnt a big issue fmpov

it would be good to actually share interfaces though

Lyza0: You can't make local scanning much faster because 1) you need to sync the whole blockchain first 2) you need to make one DH key exchange for every output in the blockchain.

I think local scanning is plenty fast, tbh. The issue with local nodes for the "average user" is that managing it through the GUI is 1) very clunky 2) means the node is out of sync when they start their wallet because it closes when the wallet closes. so for local nodes it's more quality of life stuff than raw speed imo. even for remote nodes, it's not that bad, but when using the GUI in simple mode users tend to get stuck with

unreliable nodes. and I get these aren't research topics per se but it's connected to how many people say 'fuck it' and go with MyMonero.

fwiw I'm not speaking against view tags, but this is the community that encourages (or used to) everyone to run their own node, and now we're making major protocol decisions around people who are determined to give away their privacy? I understand these services can impact everyone's privacy so it's wise to address the issue, I just wonder if we're not going the wrong way by trying to make third aprty scanning private instead of

discouraging it as much as possoble

I think it's a valid topic for discussion, if it's worth the extra 48 characters in every address and the extra complexity in the specs. Feel free to comment here: gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

The original Jamtis spec is a bit less accommodating for 3rd party scanning, but still quite a bit more private than sharing a view key today.

thanks tev, I left a small comment but felt what I was saying above was a little high level for what's become a very detail oriented conversation