MRL meeting here in 3 hours

compdec: Text only

Meeting time: monero-project/meta #873

1) Greetings

Hi

Hello

On Monday, for the wallet meeting, we were only 3 as well ...

compdec's messages aren't getting through to IRC. I may have to informally relay. I heard that the Libera<>Matrix bridge is having trouble. Maybe mine get through OK since my Matrix server is monero.social

compdec says hello

Ah, ok :) Can you read me?

2) Updates, what is everyone working on?

me: Working on a fix to the ring member dependence issue. I have an update or two on that.

rbrunner: Yes, but maybe 30-60 second delay

Pfff...

I can chat from IRC. Potential agenda: compdec's initial work/findings, hard fork readiness/justification criteria, ring member dependence issues.

compdec: "I've got a number of progresses that I'll have a written report on next week. I can discuss anything in particular. There will be a few code updates before that as well."

I tried to join on Matrix, didn't work, "There was an error joining". Splendid.

compdec: To start, which research questions were you able to come to some conclusions on?

I can at least *read* Matrix. If we don't have somebody else right now on the IRC side, no need to manually relay

hi (sorry late)

Is it logged if not relayed ?

moneromooo: AFAIK, if it's not relayed to IRC, then it is not logged at libera.monerologs.net

Strangely, monerologs.net seems to be complete - at least right now

rbrunner: I don't see anything from compdec there

compdec: "The one thing I can say for sure, is things seem a lot more mixed now than when I did my investigations a few years ago. I think conclusions is still too strong a word at this stage, I'm working on some tests today, but soon as I'm convinced things are doing what I think they are doing they'll be in the MRC [Monero Research Computing Server] for anyone to play with."

me: working on noise protocol and doing drole CI stuff for lws

Ah, right

vtnerd: Thanks. If there a document or something that we can read about which threat models the noise protocol is designed to defend against?

Sorry to spam, test, test

I posted a PR that talked about this a while ago:https://github.com/monero-project/monero/pull/8028

compdec: I think there is a breakdown of the bridge that connects Libera IRC to Matrix servers. Sorry this happened during your first meeting :(

in that PR, but basically the only threat it potentially prevents against (above SSL) is DPI fingerprinting

There are desktop and mobile apps for Matrix element. I don't know if you would be more successful with that with the bridge having trouble.

although with the consistent port numbers, its probably pointless (without promoting random port numbers)

Howdy, sorry I'm late

vtnerd: Thank you!

the other trouble with SSL or noise, are the strategies during the "upgrade", where some of your peers support encryption but your local table hasnt been updated yet

jeffro is on the monero.social home server and it's being relayed to IRC. May be a home server problem with matrix.org

SSL vs noise have different strategies for this

lastly, I choise noise simply because two community members recommended that over SSL, and there wasn't much movement against in an GH issue that is still posted

vtnerd: One advantage using SSL over noise is that we can "hijack" the 443 port to hide Monero network traffic among normal web traffic, even on the same server (using reverse proxies)

xmrack: But your messages aren't being sent to IRC

compdec: "One interesting thing I'm finding is that some analogy or the EAE problem is already present at the level of ring correlations."

I recently started thinking about that advantage of SSL when I tried to resync my daemon in an airport. A lot of WIFI hotspots try to limit traffic to certain protocols. If we use SSL, we stand a higher chance of blending in with web traffic and skirting less advanced network controls

jeffro256[m]: possibly, but low port numbers often require special permission

we could combine it with a patch that "steps down" permissions

I'll think about this the next few days, one of the difficult points is detecting when the peer supports encryption and how to upgrade it

with noise I can control 100% of the data flow, but with SSL Im not writing my own implementation so we have to work-around an API

vtnerd: Could a hard fork boundary be used to make sure all peers support encryption? What do you think about that?

selsta's new CCS proposal ( repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/404 ) says "Continue the planning of a network upgrade with RandomX changes (monero-project/monero #8827) and Bulletproofs++"

I think OSPEAD should be added to that list. Where do the RandomX changes and BP++ need to be to be considered ready for a possible hard fork?

Liam Eagan say that the BP++ paper was submitted to this conference. Apparently it wasn't accepted: sp2023.ieee-security.org/program-papers.html

That doesn't mean that the paper isn't good. Just maybe not a good fit for the topics in the conference. This means that the paper has no peer review still.

rucknium[m]: I discussed this at monerotopia22, the seth pointed out that we may not want to make encryption mandatory, so that theres a fallback

For BP+ (one plus) there were two audits. Maybe at least one would be considered a review of the math. Do we want to do that again for BP++?

the difficult part is that the p2p connections persist "through" a hardfork, but it could sort-of be done for making new connections

vtnerd: I see. Thanks.

vtnerd: Assuming that 1) everyone is using the core project's daemon and 2) we know all nodes have integrated the p2p encryption code since the code was merged before the most recent hardfork, why would want to allow unencrypted connections?

I'll give my update on OSPEAD: I tried a quick fix to the ring member dependence issues and...

it was a complete failure. lol

Maybe a different quick fix would not be a failure, but that one was.

Rucknium[m]: What did you try?

I am still evaluating the "long fix". Getting a little more pessimistic about that one, too. So maybe we would accept some inaccuracy. Close doesn't count, except for horse shoes, hand grenades....and statistics :)

compec: "perhaps I should ask in the dev channel when finished here, but I have some questions on the state of the decoy selection"

Maybe jeffro256 can answer some questions about the state of decoy selection

I'd be happy to ;)

jeffro256: I tried something that eliminated the correlation between ring members, but that had unintended consequences that destroyed the final estimate.

jeffro256[m]: that was my initial thought, seth convinced me otherwise at the conference but I dont remember his argument :/

it should be on video

That is, taking a dataset that has some correlation and transforming it to have no correlation. (Instead of starting with an uncorrelated dataset to begin with, which the current OSPEAD estimator happens to handle extremely well.)

compdec: "I'll put it here then. It seems that there is a window for recent transactions and after that, things are called from a log(beta) distribution. Is there an empirical distribution that is being measured and drawn from for the recent transactions?"

compdec: "Basically I'm trying to look at a ring, choose subsets of that ring, and test the likelihood that configuration could have come from the decoy selection"

<compdec[m]> "I'll put it here then. It seems..." <- The current decoy selection algorithm takes a gamma (log) distribution, more or less uses that as a timestamp to index outputs. The gamma distribution is distorted based on the output volume per block, but there is no empirical distribution to speak of in Monero since the distribution of true spends is obfuscated by nature

IIRC, Rucknium uses the Litecoin spend distribution as an empirical "ground truth" and compares spending in Monero to that distribution

(In OSPEAD)

I am using LTC as a test for the Monte Carlo. I know the LTC real spend, so I can tell if the estimator recovers the correct real spend distribution. OSPEAD will be used on Monero's data for the final estimate.

We don't know the ground truth for Monero. The estimator's output is supposed to be the best guess.

We don't know the ground truth for most things in statistics, which is why we use statistics in the first place :)

Rucknium[m]: Yes, sorry I worded that badly but that's what I'm getting at (which is what makes Rucknium's work so hard); there's no way to tell what the actual distribution of true spends in Monero is *by design*.

The decoy selection has gone from an even distribution, to a triangular distribution, to a gamma distribution

compdec: "I see. I thought it was a beta distribution, which had support from 0 to 1."

compdec: "How does the distortion by volume happen? It seems that there is some stationary component as well as some non-stationary component"

("even" = uniform distribution)

The RPC endpoint /get_output_distribution lists the number of outputs for a given amount at each block. This data is used in the DSA to more heavily weigh times of high transaction output

Mobilecoin and Zano are still using a uniform distribution AFAIK

(DSA = Decoy Selection Algorithm)

We can officially end the meeting here. Conversation about what exactly the Monero DSA is doing can continue of course :)

<plowsof11> "File transfer speeds are greater..." <- Sort of... With encryption there's a greater latency b/c you have to perform decryption after receiving the data, but most modern encryption schemes don't actually increase bandwidth requirements beyond a couple of bytes for IV, nonces, etc. So for one-way downloads, if done correctly, encryption shouldn't really affect download speeds

Thanks Ruck