-
Rucknium
MRL meeting in this room in two hours
-
Rucknium
-
Rucknium
1) Greetings
-
tevador
Hi
-
rbrunner
Hello
-
m-relay
<vtnerd:monero.social> Hi
-
m-relay
<murksombra:matrix.org> hi!
-
Rucknium
2) Updates. What is everyone working on?
-
m-relay
<vtnerd:monero.social> me: finished testing up P2P+SSL, and pushed a PR. Also working on subaddresses (more this week than last)
-
m-relay
<vtnerd:monero.social> cryptogrampy: made some good comments (on subaddresses+LWS) that I will address
-
Rucknium
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
-
tevador
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-relay
<murksombra:matrix.org> me: joined yesterday. Catching up with current developments and see where I can contribute.
-
Rucknium
murksombra: Welcome! Do you have a specific area you are interested in?
-
m-relay
<vtnerd:monero.social> tevador: where is this discussion taking place? I need to at least watch the discussion for LWS purposes
-
m-relay
<murksombra:matrix.org> I can help from coffee to cryptography :)
-
tevador
-
m-relay
<murksombra:matrix.org> mostly cryptography I should say :)
-
rbrunner
You can never have enough cryptographers, it seems sometimes :)
-
rbrunner
Er, *too many
-
Rucknium
murksombra: Great. The main cryptography things happening are Seraphis/Jamtis and Full Chain Membership Proofs using Curve Trees
-
m-relay
<murksombra:matrix.org> ack. will check.
-
m-relay
<murksombra:matrix.org> but again, I can war multiple hats and contribute in other areas as well. Hardening, OPSec yadda yadda
-
Rucknium
3) Discussion. What do we want to discuss?
-
rbrunner
Maybe, as tevador is here, a question from me
-
Rucknium
tevador: Do you want to summarize the main points you want feedback for the changes to Jamtis specs?
-
rbrunner
Right, that was also my question :)
-
rbrunner
Where do we stand with that? Still fully open? Slowly converging towards an improved Jamtis?
-
tevador
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.
-
tevador
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.
-
tevador
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.
-
tevador
Or more likely would have to switch to a less private wallet tier.
-
Rucknium
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.
-
tevador
The proposal would increase address length from 196 to 244 characters, but that's still withing an acceptable range.
-
Rucknium
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?
-
rbrunner
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?
-
tevador
Yes, the view tag size adjusts automatically by using a formula based on the number of outputs in the last 100 000 blocks.
-
Rucknium
Addresses do not change when the view tag size changes, right? So an address would be valid both before and after adjustment?
-
tevador
No, only the view tag inside transactions changes.
-
tevador
It's meant to adjust to follow long-term tx volume.
-
tevador
100 000 blocks is also what the block size limit is based on
-
rbrunner
About 4 months
-
tevador
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).
-
tevador
The size is adjusted for 1 false positive per block on average.
-
Rucknium
What is "one false positive per block"?
-
tevador
Besides the outputs you own, the view tag will also match, on average, 1 output per block that you don't own.
-
rbrunner
A tx sent to somebody as "probably yours" but turning out not be such?
-
rbrunner
Over all tx receivers of the block, right?
-
tevador
Every wallet will calculate a different view tag for every output, but on average, everyone will see 1 false match per block.
-
tevador
This is done to hide your real outputs from the 3rd party scanner.
-
rbrunner
Ah, ok
-
Rucknium
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.
-
tevador
The 3rd party scanner will send all matches to your wallet, so you have to scan only 720 outputs per day.
-
rbrunner
Is this a new idea? Making the view tags *less* precise?
-
tevador
I think so. View tags that are too precise would basically leak your outputs to the 3rd party scanner.
-
rbrunner
I mean was this already a consideration when we came up with the current 1-byte view tag? Maybe not
-
tevador
The difference is that whoever can calculate the current 8-bit tag can also fully recognize owned outputs. That changes with Jamtis.
-
tevador
Jamtis has one key that can only calculate view tags. Another key is used to actually calculate if the output key is yours.
-
rbrunner
I see
-
tevador
There are basically 3 different levels of "view only" wallet rather than just one level.
-
rbrunner
Does sound quite attractive, that dynamically sized view tag.
-
Rucknium
UkoeHB said in the Sept 11 No Wallet Left Behind meeting:
-
Rucknium
"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."
-
Rucknium
Is there general agreement on this point: "if a user can't local scan then they are out of our design space"?
-
tevador
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.
-
rbrunner
I think it's a bit hard to find the proper context of that opinion stated by UkoeHB
-
rbrunner
There was much back-and-forth discussion by him and jeffro256 about this
-
rbrunner
with a large numbers of different arguments
-
tevador
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.
-
rbrunner
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
-
rbrunner
E.g. don't use for a few months, wait hours until synced again
-
Rucknium
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 :)
-
tevador
Yes, our goal is to have a precise specification.
-
rbrunner
Including the times around switching bit size, which may be a bit tricky
-
Rucknium
because I know a lot of them don't know what to do with fees.
-
rbrunner
Well, maybe they are just lazy to implement it properly :)
-
tevador
Yes, we don't want the tag size to create anonymity puddles, so the size will be enforced by a relay rule.
-
Rucknium
-
tevador
Wallets that cut corners and hardcode the size won't work.
-
Rucknium
I'll quote the main point from the abstract:
-
Rucknium
"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
-
Rucknium
blockchain that have the defect."
-
Rucknium
"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."
-
Rucknium
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
-
Rucknium
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.
-
rbrunner
Agree
-
Rucknium
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.
-
Rucknium
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 ;)
-
Rucknium
I wrote a Monte Carlo simulation, too, and it gives the same values (within epsilon) as the closed-form expression I developed.
-
tevador
Hopefully, these problems will disappear with full chain membership proofs.
-
tevador
Or at least be much less severe.
-
m-relay
<murksombra:matrix.org> is this public?
-
Rucknium
Yes, much less severe. Only really rare defects would be a problem with full chain membership proofs.
-
Rucknium
-
m-relay
<murksombra:matrix.org> ty
-
Rucknium
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.
-
m-relay
<rucknium: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
-
Lyza0
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
-
Lyza0
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
-
m-relay
<endor00: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
-
m-relay
<endor00:matrix.org> And without viewkeys, you cut down on one of the fundamental privacy features of Monero
-
sech1
Without view tags, people will just use private viewkey for scanning (like MyMonero does), and that's even worse
-
rbrunner
And view tags are not only for third-party scanning. Scanning the blockchain yourself also profits from them, of course.
-
rbrunner
But yes, Jamtis and Seraphis are very complex beasts already, and Jamtis seems to grow a little more still now.
-
rbrunner
One can somehow wonder what's wrong with this universe that a private cryptocurrency needs such a crazy big machinery
-
rbrunner
Or maybe just nobody found the breakthrough yet ...
-
endogenic
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
-
endogenic
some big stuff
-
endogenic
the lws code came from wallet2 originally so converging isnt a big issue fmpov
-
endogenic
it would be good to actually share interfaces though
-
tevador
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.
-
Lyza0
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
-
Lyza0
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.
-
Lyza0
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
-
Lyza0
discouraging it as much as possoble
-
tevador
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
-
tevador
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.
-
Lyza0
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