Is there a high resolution logo of the MRL? monero-project/monero-site #948#discussion_r444892332

Or do you know where could i find other logos? I didn't find much

What's the resolution available now?

I don't have anything available except what goes on the MRL non-IACR preprints

this is 255px × 255px and it's also quite heavy. I might have taken it from the matrix room of this channel

sarang could you give me a link to the version you use for preprints? maybe it's better

e.g. github.com/SarangNoether/research-l…ulletins/MRL-0010-discrete/logo.png

Maybe there's an SVG somewhere; I'm not sure though

I think that's the same, but i will see what i can do. An svg version would be perfect

Can't help you there, unfortunately

Maybe someone like fluffypony would know if such a thing is floating around somewhere

That logo has been around for a few years now

I made the logo

lol

I have it in PSD and AI

I can export AI to SVG

last time it was edited lol

Didn't know that. :)

A svg version would be great

you just need the actual logo not the text, right?

Yes only the logo

ErCiccione[m]: what's the best way to get this to you? Telegram / Wire / email?

Email would be best. translate⊙go

GitHub won't let me upload an SVG to that thread lol

Thanks!

Thanks fluffypony

np

ErCiccione[m]: add to press kit page?

for easier access

Oh yeah, that's a good idea

I'm opening an issue about it and i will add it later on. There is no place to put it with the current structure and should be also included in monero-press-kit.zip

Don't forget there's a weekly research meeting today at 17:00 UTC

.time

good bot

I'll talk a bit at the meeting about the status of the CLSAG review

having an svg would be great

@xmrpow I'm working on designing a PPS pool and crunching those numbers is on my to-do list. Also working on a ramp mechanism that brings some PPLNS principles (more like PPFNS, actually) into our PPS pool to protect the operator against getting financially pinched by pool hopping

Happy to collaborate via direct message or Isthmus [at] getmonero.org

Oh shoot, did they leave already?

Isthmus: xmrpow always leaves but keeps on watching the logs

OK, let's go ahead and get started with the meeting

Logs will be posted to the agenda GitHub issue after it's finished

First, GREETINGS

Hi

0/

Greetings

All right, on to ROUNDTABLE, where anyone is welcome to share research of interest

Who would like to go first?

Isthmus:?

Heyo

Update on quantum audit, here is our preliminary analysis existing vulnerabilities. (Results subject to change as research progresses!)

It's kind of a mixed bag, tbh.

To be expected, I suppose

There are many components of interest

Our reliance on DLP is the biggest weak spot right, as expected

ya

That's all on that, any Q's?

By "ring signatures" I assume you mean a quantum adversary identifying signing indices via key images?

Yea (or via any mechanism)

Oh, one thing that we started wondering about

If you're creating a multisig transactions and one of the signers has a quantum computer, can they gain any extra information about their co-signers

Well, you can just derive the whole private key

if that's what you mean

Yea. I need to sit down with ZtM2 to figure out what's passed around, and what should be unknown, just crossed my mind yesterdy

That's a good point

I don't think anyone had specifically mentioned the multisig process during the planning stages of your analysis

Yea, we just added it. Will probably realize 1 or 2 more aspects to check throughout the next few weeks

Keep dropping us your ideas :- )

Are there particular assumptions made about whether or not the adversary has a public key already?

e.g. the adversary suspects a particular address as a destination

I'm assuming that the adversary is a co-signer on the multisig transaction. They would know the public key with or without a quantum computer, right?

[erm, well we can consider the adversary both ways, this is just what I had been wondering about yesterday]

I mean in general, sorry

Not specific to multisig

Ah yea, quantum computer with your public key and quantum computer without your public key are two adversary models that are considered separately.

Though TBH the first one is pretty (sadly) easy

Public key --> [shor's algorithm] --> private key --> init wallet --> game over

sorry I'm late

And not even "your" public key

But just looking at a given transcation on chain

If the adversary's goal is to identify as much as possible about keys, addresses, etc.

Sending wallet address, receiving wallet address, etc.

Yea, if an outside observer plucks a transaction at random from the blockchain, with no further knowledge, what can they ascertain about 1) the sender, 2) the transaction, 3) the recipient

Right. And then what can they learn if they have an idea of possible addresses

Bingo

I assume that there is (or will be) a more specific write-up with details on what relates to this chart?

Earlier I argued you could brute force output amounts if the DLP is broken (assuming recipient address is unknown), however I'll retract that. Output amounts are information-theoretically secure.

Gotcha

Yeah, this will all be in the research writeup, and more intuitive parts will be included in the general audience writeup

Anything else to consider about your analysis at this point Isthmus?

We were thinking about some medium articles throughout, just for good measure

Nope, that's all on the quantum end for now

OK great!

I started going down a rabbit hole of subliminal channels this morning, but will save those thoughts for later

Did anyone else wish to present research of interest?

This means even if both DLP and hash preimage are broken, there should not be a way to extract the recipient's address from an output.

That's a huge relief, or else we could recursively apply Shor's algorithm and move forward through the transaction tree breaking everybody's wallets

I'll share a few things

Here's a time-windowed CDF of spend age: usercontent.irccloud-cdn.com/file/5EccXpmE/cdf_window.png

Still tracks the gamma distribution pretty well, but there are differences over time (pre-CT)

Related to this, I posted my tracing code: github.com/SarangNoether/skunkworks/tree/tracing

It now supports iterative updates, which may be useful

Unrelated to this, I'm still working with the CLSAG auditors

I rewrote the proof for Theorem 1 that relates unforgeability to non-slanderability, and it now addresses the auditors' suggestions

There are a bunch of other non-security-related updates to it

and I'm now in the process of overhauling the linkability anonymity proof to use a better hardness assumption and method, which is a tedious process

but I think that will address their comments and be a stronger result

The auditors' conclusion is that the construction seems secure, and that the security model seems appropriate to the use case

This was the overall goal of the audit; suggestions relating to presentation, formality, etc. are very useful for later submission, but don't appear security-related

Sounds like the audit is moving along well

It is! The code review portion has not begun yet, but there are no changes in code to be made as a result of the preprint audit at this point

Any questions on these research topics?

OK, did anyone else have anything to share before we move on?

nope

If not, we can move on to ACTION ITEMS for the coming week

I will be finishing up this linkable anonymity overhaul and incorporating it into the preprint, which will complete the updates needed for the auditors

Once that's done, I'll get the preprint in a submittable state

Anyone else?

I'll be opening a GitHub issue for segregating coinbase outputs into coinbase-only rings

It's a good time to discuss this, with an upcoming network upgrade for CLSAG at some point

yeah I think so too

especially given the spend-age data

I'd still love to see the corresponding data for bitcoin

but I don't have that dataset

all the Monero data is necessarily pre-CT because of deducibility

and any post-CT deducible data spends old funds and is therefore basically useless for those kinds of distributions

I've been pretty clear that I think this BTC data would be nice but isn't necessary to make this change

understood

OK, anything else before we adjourn?

Isthmus I have to walk back my walkback (sorry for the interruption sarang). You can definitely brute force it if the DLP and hash preimage are broken. Information-theoretic security means nothing in the face of brute forcing all possibilities (64 bits worth). You'd 1) get the DLP of generator H and the commitment C, 2) pick an amount, 3) compute the possible derivation to scalar, 4) get its hash preimage,

4a) use the key sequence of bits from the preimage to test the encoded amount and only continue if it matches the guessed amount (very unlikely to match if the guessed amount isn't correct) 5) use the key sequence of bits from the preimage to compute the one time address derivation to scalar, 6) subtract it from the one time address private key to get the nominal private spend key, 7) get the DLP of the

preimage key with respect to the tx pub key to get the nominal private view key, 8) test if the spend key can produce the view key directly (normal address) or if any reasonable sub address index can be used to extract a spend key that produces the view key, 9) repeat 2-8 until you get a match (step 4a will probably catch most mistaken guesses). Let's blame this mishap on a stray synapse.

hmm

ohhhhhh

IIRC preimage on keccak is something like O(2^100) or so

but I'd have to check on that

Unrelated: Does ZtM2 talk about variable types or just math? Trying to figure out if fees are uint64 or what

They are varints, which I mention in section 6.3 footnote iirc

Ah, perfect. Thanks!

Righto, let's go ahead and adjourn since it's now 18:00 UTC

Thanks to everyone for participating!

UkoeHB_ Isthmus: specifying some complexity bound may be important

Even if the preimage is broken you'd still have to pick the right preimage, which may be more difficult. The input is something like 100 bytes, since there is a string input (~8 chars?)

You mean the fixed domain separators?

Right

Those are fixed

Right, but doesn't it depend how the preimage is broken? If it's easy to find 1 preimage, it's not necessarily a useful one, or even one with the right number of bits

Finding one preimage may be considered easy, while the correct preimage is hard/expensive

Or even a nominally correct one

Oh I see what you mean, since you need to perform additional work on particular preimages to actually gain anything useful

right

Ah interesting

Does anybody have number of RingCT outputs handy?

I know we dug it up in Noncesense DB a while back but I've lost track

Should be: ./external/db_drivers/liblmdb/mdb_dump -s output_txs ~/.bitmonero/lmdb | grep -E '^\ [0-9a-f]{96}$' | wc -l

(running)

Need it for any particular analysis?

40258823

Oh, you know what. I counted all outs. nvm.

18407972

That includes the v2 coinbase outs, which are deemed rct.

ty

Thanks, I'm just braindumping stuff here: github.com/Mitchellpkt/subliminal_channel_audit/blob/master/README.md

Definitely not a comprehensive list, please add your ideas :- )

To keep up in the future: output_histogram @0

What's the threat model for this Isthmus?

In the case of a compromised wallet, you could lose all fund

*funds

Exchanges might be less likely to pull such shenanigans

And `tx_extra` is by far the most straightforward way to include information

as you well know

This also seems somewhat related to previous preprints that identified ways to covertly (or not-so-covertly) generate transactions with provably-spent outputs

One example was to use `N` identical rings of size `N`

But this generalizes to the subset technique discussed in one of my MRL preprints

MRL-0007

I view surveillance and theft as two separate threats.

You can imagine entities (AdTech sector, exchanges, governments, compliance entities, abusive exes, etc) who would be highly interested in surveillance and not theft.

And if your goal is surveillance, then any theft would be highly counterproductive!

As soon a you make an unauthorized transaction, user freaks out and gets new seed/software/tech support, so you shoot your surveillance campaign right in the foot

Then user goes to reddit and everybody else uninstalls your thieving wallet

But silent surveillance could go unnoticed for years if not indefinitely depending on the subtlety of the encodings

If I worked in AdTech I'd release a really handy web browser extension Monero wallet for shopping, and then use subliminal messages to encode the domain of open tab(s) so I could start to build activity profiles

If your messages were superliminal, you could get a Nobel.

Ahhahaha

How do you view the risk of surveillance?

If you're installing malicious code, that itself is a huge vector for risk

I get the idea that applying some kind of intentional transaction fingerprint is bad, and I agree that transaction structure should be as uniform as possible anyway (even in case of unintentional fingerprinting)

but I want to ensure that I fully understand what risks you're looking at that wouldn't already exist from malicious software

The threat that I can see with this is if you assume the user can detect shady activity on their local device (standard malware detection?), but could not detect data exfiltration via transaction submission

That seems a bit iffy to me

In the example of those preprints that wondered what would happen if different entities hid their spent-output data in repeated or overlapping rings, one could imagine that it's surely easier for such entities to just use a side channel to identify their transactions, for example

Meaning IMO the marginal risk is super low

Not saying the overall risk is super low, just the marginal risk of such an on-chain method

I missed the meeting

Oh boy

needbrrrrrrr90: any questions/comments/etc.?

Logs available on GitHub and the log link in the topic

Gotta catch up first

I just woke up ;_;

heh welcome to the world of the living needbrrrrrrr90

Isthmus presented some post-quantum research results

I talked about security proofs

a whirlwind tour...

Ooh

Quantum stuff

Isthmus's material was more interesting than mine :/

(yes I know quantum summons isthmus)

(quantum quantum quantum)

Unless you're really into security models

Lol

Oh, and worth mentioning that the CLSAG audit (related to the security proof stuff) is going very nicely

this is monero after all ;)

No major issues with the preprint

But great suggestions on improvements, most of which are already done

I missed the meeting too, had a sched conflict. but looks like all good news

The last remaining thing is this security proof, for which I want to do more major revisions that will take a bit of time due to the subtlety

At any rate, no code changes needed as a result of the preprint audit

The auditors have done a wonderful job, and have been super responsive to my questions/comments

Anyway, don't expect any tangible results on that until I get the proof stuff worked out on paper and then typeset

After it's all done, I'll update the preprint on IACR and link it here

Until then, it's just a ton of notes on paper :D

I'll leave this for comment here before I share on Reddit and Twitter

You have been pushing this forever now. It should *only* get done *if* MRL gets a consensus that it is a good thing to do. Trying to get social pressure from random sybils makes me look pretty dimly at it.,

moneromooo: One thing I don't recall discussing was any added storage/indexing complexity for doing a separate gamma pick on coinbase outputs

In this case, I assume you'd do gamma on blocks instead, ignoring the weighting/shuffling portions we do now

I do agree with sgp_ that it provides a benefit overall. I still hold that it makes certain heuristics somewhat marginally harder (but not necessarily significantly)

moneromooo: my intent in sharing it was not to try and sybil with randos

I *think* that currently it'd be about the same (no added performance/memory), but that's assuming 1 coinbase out per block. Which is te case in practice, but not enforced.

(and would not be the case with something like p2pool)

In the case of multiple outputs, the current weight+shuffle method would work, albeit just on a list of coinbase

choose-by-block is just the trivial version of that

(since all weights are equal if you assume 1 coinbase/block)

I'd like to devote some time in next week's meeting to specifically discussing the benefits and risks of this idea (and certainly discuss in the meantime)

With more than one coinbase out per block, you'd need to send the number of sych per block in addition to the nubmer of total outs per block. So twice the data I think.

I guess you could get clever and send separate data only for those blocks that have > 1 coinbase out.

Which would be... no extra data in practice for now.