meeting ~1hr: monero-project/meta #668

has this been discussed? eprint.iacr.org/2021/089

they seem to add fuzziness to the view tag, not the FindReceived key

Meeting time

1. Greetings

Hello

Hi

hello

Hi

Hiya

Hi

sgp_: view tags are already fuzzy

UkoeHB: oh yeah, of course duh. Sorry :)

however if you can compute a view tag then you can also compute a nominal spend key, which reveals more info

but we need that for efficiency on the client side

2. let's do updates, what is everyone working on these days?

The MAGIC Monero Fund has its first research grant application, by xmr-ack :

me: I finished my CCS ( repo.getmonero.org/monero-project/c…als/-/merge_requests/256#note_15087 ) and plan to make a new one today.

The general idea is to see how accurately machine learning techniques can identify the real spend in a ring, using a synthetic dataset.

The MAGIC Monero Fund is asking MRL for feedback on the grant application. Of course, the final decision rests with the committee.

Maybe isthmus would have some input given his experience with machine learning.

Is that the background of the currently very high tx traffic on testnet?

rbrunner: Yes.

Sounds like an interesting project.

For a layman like me, at least

I'm wondering how you translate results/models obtained for a synthetic data set to the real data set.

oh jesus he's using the public testnet?

You did not notice that huuuuuge amount of traffic there over the last 3 weeks? :)

ugh thats unnecessary

Not sure. As soon as somebody wants to confirm results, a public blockchain may be very handy

Also, plowsof and I set up an instance of WIKINDX at moneroresearch.info . It's a place to collect Monero-related papers and annotate them. My hope is that it can help onboard new researchers and help us establish a workflow for reviewing new papers that are written about Monero.

I've disabled public user registrations to avoid vandalism, but if anyone wants to create a user to be able to add, edit, and add annotations to papers, just message me and I will create one for you.

also, stagenet might potentially be better. testnet could get hella ugly if/when we actually test the new release. the randomx testnet was brutal

but yeah rbrunner re: public blockchain reproducibility considerations.

Hopefully that WIKINDX thing does not need to much babysitting and does not surprise with new security holes every fortnight :)

rbrunner: WIKINDX has been around since 2003 apparently. It was hard to set up, but hopefully it is "mature" by now.

3. I guess we can move to discussion. Any items to discuss? Perhaps from the agenda

and UkoeHB re: synthetic vs. real data. I share the same curiosity, and i'd propose to use the bitcoin blockchain with ring sigs superimposed somehow

but, its good to do things in multiple ways i guess

I have a question that may be of wider interest and was brought up by a recent video about Seraphis:

I refer to the following article: getmonero.org/2021/12/22/what-is-seraphis.html

gingeropolous: yeah you could probably generate the bitcoin blockchain with ring sigs all offline.

Under "membership proof delegation" it mentions that this may open up the following possibility:

Ignore 10-block lock time when transacting with a *trusted* party (i.e. allow them to make your tx's membership proofs and submit the tx to the network on your behalf).

Is that still current? And if yes can you sketch what that means and how that could work in practice?

rbrunner: You would send a `PartialTx` to your friend, and then later they can make membership proofs for the tx and submit it.

this guy: github.com/UkoeHB/monero/blob/bd46a…eraphis/txtype_squashed_v1.cpp#L183

err actually would be this one in practice lol: github.com/UkoeHB/monero/blob/bd46a…eraphis/txtype_squashed_v1.cpp#L201

And it's trusted because by building such a partial tx and sending it to my friend, I still could spend faster and cheat?

that and your friend will know the real spends

But I could send such a partial tx very early, within the 10-block spend limit?

<UkoeHB> "I'm wondering how you translate..." <- This is the reason I choose to collect it on the test-net, I need the data to resemble main-net as close as possible. With machine learning, small discrepancies in the training dataset compared to the testing dataset could result in large inaccuracies. I understand a large amount of traffic on the test-net is not ideal, so I'll soon be delaying transactions based on real-user

spending patterns.

but where are u getting those spending patterns?

rbrunner: yes

<gingeropolous> "also, stagenet might potentially..." <- This might be a good common ground.

yeah. testnet has the potential to get restarted, or rolled back, during dev testing etc

could really muck up your work

Alright, so that's only a "reduction" or "circumvention" of the 10-block limit in quite special circumstances. And I guess final submit has to wait then?

xmr-ack: One good reason to do it on testnet or stagenet would be if you were using network data as features for the machine learning algorithm.

rbrunner: right

Ok, thanks!

stagenet shouldn't be fiddled with in that way. stagenet is meant to mimic mainnet, just not have any value. testnet is meant to test consensus rules etc. at least thats the thought. but testnet only really got mucked with during the randomx testing as far as i recall.

delegation is more useful for multisig, tx chaining, collaborative funding

gingeropolous: The gamma distribution proposed in Moser et al. Additionally, I'm going to run an experiment soon where I crawl the last 1,000,000 transactions on main-net using the onion block explorer and calculate the distribution of transaction fees to simulate that as well.

gingeropolous: I didn't know this. That could be a problem

xmr-ack[m]: is there an advantage to generating real txs? your database just reduces to {block height, {reference heights}}

Well, testnet was quite stable for a long time now.

we haven't had to test new consensus rules :)

True.

i mean, the new ones shouldn't be that fiddly, but who knows

<Rucknium[m]> "xmr-ack: One good reason to do..." <- I have thought about incorporating network features and even ran some experiments in the past where a 1D conv-net was able to differentiate between remote node network traffic with a > 90% accuracy. But that was a quite small dataset and only preliminary results.

UkoeHB: I have some code here that simulates different wallet version strategies to arrive at this FWIW: j-berman/monero 4baf4c9

i dunno about network features. the permanent thing is the blockchain

<UkoeHB> "xmr-ack: is there an advantage..." <- My reasons so far include:... (full message at libera.ems.host/_matrix/media/r0/do…54db00368e85005a07d2021036b621cd66d)

Monero adversaries almost certainly are collecting more than just blockchain data.

gingeropolous: I agree

Rucknium: They are but I think specifically for this research project that is out of scope. I may continue my research down the road and look into fingerprinting network patterns between: peers, remote nodes, etc...

Fingerprinting network patterns is really cool because you can pretty much bypass all encryption.

Uh, you may elaborate a bit, otherwise people will freak out reading the log of this meeting ...

* all encryption. Granted you can only classify high level actions ( ex. user spent monero vs user recieved blocks)

Yea I just edited hahah I realized that needed more context

Let me find a good paper for anyone thats interested

"Monero researcher finally admits: Monero *is* traceable" :)

~never~

Dandelion++ is supposed to reduce the efficacy of de-anonymization efforts based on monitoring network data, I believe.

Had the same thought, yes

I think we can call the meeting here, unless anyone has any last minute comments/questions.

ok thanks for attending everyone

Rucknium[m]: Yea good point. To clarify, the research scenario where traffic patterns could be fingerprinted were only tested in a highly privileged network location. ( ex. a local adversary that could view encrypted packet patterns )

* packet patterns before the traffic reached the remote node)

I don't know much about ML, but doesn't training usually occur with real data, rather than simulated data? i.e. if you're training some model based on simulated data, or data that you control/are creating, doesn't that bias the model toward whatever data you generate, and therefore defeat the purpose of trying to match "main-net conditions", since it trivially is not those conditions, but the conditions of what you created? idk

if that makes sense

With the small problem how you test for correct results on mainnet, maybe?

Maybe a quite special case with Monero where your data actively resist analysis :)

jberman[m]: you're totally correct.

<jberman[m]> "I don't know much about ML..." <- Correct, but using test-net or stage-net is the best conditions we have. Collecting the dataset on main-net is not financially feasible and publicly disclosing the true spend of a large number of transactions would have serious privacy implications for other users.

* other users. There is still likely many features within test-net that can be applied to main net.

xmr-ack: any ... thoughts on using bitcoin data and superimposing ringsigs on top of it?

gingeropolous: I mean I could try it but then I can't imagine that dataset working better than true monero transactions.

i think both approaches are worth it

I think it would lose a lot of the value from test-net

honestly, a ML model should be able to do both

Let me post my feature-set ideas to the github proposal

<xmr-ack[m]> "Correct, but using test-net or..." <- ok, but it would seem like you'd need to exclude your own data from the training set, no? cuz including your own data kinda defeats the point of matching any real world conditions?

i.e., one trained on fake data should be able to deconvolute one created from the bitcoin superimposed one

jberman[m]: Potentially, it depends on if the model overfits the training data or not. There are ways to combat this, such as hyperparameter tuning and reducing the number of parameters in the neural net.

Okay I just added the feature-set ideas to the proposal MAGICGrants/Monero-Fund #15

These are just ideas not set in stone. If anyone finds an error or has a suggestion, please let me know!

Another idea, maybe related to gingeropolous 's idea, is to leverage the real spend data from the Moser et al. (2018) paper. That data is outdated, however.

In other words, reproduce the spending patterns from that data, but with current-version Monero transaction types. That's a lot of coding though....

Rucknium: I don't think I ever found their actual dataset, I know their github repo has the code to make your own dataset though. If you have it could you send it my way?

jberman reproduced some parts of the data somehow

Rucknium: I think re-assessing the spending patterns could be very interesting. I'll look into that if I have time

Adding this to the jupyter notebook after step 46 will download a CSV of the spend times they used to calculate the gamma: paste.debian.net/1232030

have that result somewhere too will send it over pm

Do they identify which transactions spend which outputs? Or only have the spend times available?

log_spend_times pretty sure is just spend times, but they also identify which transactions psend which outputs

think that query right above log_spend_times is basically just querying "what is the age of the output this transaction is spending" and aggregates the answer to that question

for all tx's they know real spends for

<xmr-ack[m]> "Let me find a good paper for..." <- home.cse.ust.hk/~taow/wf

hello

is this branch good to analise, to understand ringCT ? github.com/SarangNoether/skunkworks/tree/rct3

slave_blocker2: probably not, rct3 probably implies this paper eprint.iacr.org/2019/508

new ccs for seraphis wallet poc ( rbrunner ): repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290

Thanks for the pointer. Let's hope this will get filled as fast as your first one once published.