There is a meeting in this channel in about 40 minutes

ah crap time change

To all meeting participants: please disclose any potential conflicts of interest.

lolwut

Where did this disclosure bot come from?

secret keys too ?

disclosure-bot-x: Please define "conflict of interest"

meeting time: monero-project/meta #626 (for those who time changed, now 1700UTC comes an hour earlier)

1. greetings

hello

Hi!

Hi

Hello

Hello

Hi

2. let's start with updates; what has everyone been working on lately?

Me: I completed my Seraphis PoC for performance testing, and started collecting test results (thanks to gingeropolous for his help :)). While doing that, I discovered a rare bug (monero-project/monero #8052).

Analysis of UkoeHB 's cryptography performance benchmarks. Finished final version of OSPEAD CCS proposal. Gave initial thoughts on the "decoy collision" issue raised by an Aeon dev. Brainstorming about research-specific funding mechanism. BCH work.

If no one else has updates, we can move on. We might be missing people due to the time change.

3. discussion; anyone want to discuss something from the agenda?

Myself and spirobel are in early discussions of putting together a hub for monero-related research

Paper summaries, categorizations, RSS feeds etc. Etc.

Oh, right! I wanted to discuss that. We should make a bounty and think about what the requirements should be.

"a hub for ... research" what does it mean ?

Tentative name: "Where to Find Monero Research: moneroresearch.wtf" I bought the domain name.

wfaressuissia[m]: The number of papers on Monero being published by external researchers has skyrocketed. We are not keeping up with reading them.

wfaressuissia[m] there are many academic papers published about XMR and XMR-related topics which are basically being ignored by the visible community

Moser et al. (2018) alone now has over 80 citations.

citations don't mean that paper is the main reference

Anyways, this is very early stages so not much more to say there

wfaressuissia[m]: We don't even know that since we haven't read the papers. That's part of the problem.

thanks carrington[m]

If anyone is hiding away their own private infodump of papers and relevant research please sling it my way

I think it would be good to have a portal that automatically pulls papers and their essential data (authors, title, abstract, etc.) based on keyword search and/or when key papers are cited. And maybe even allows a permissioned login system to make brief notes about the paper.

carrington: Will do.

Rucknium[m]: like google schoolar?

Google scholar API could help, yes. There are other systems, too, that could be pulled from.

I'd be looking to write an abstract-style "how this relates to Monero" for those papers where the connection isn't obvious

Anyways, regarding actual research, is there anything we can say about these performance numbers at this stage?

UkoeHB has just generated new performance data. Is it ready for me to analyze, or still tweaking, UkoeHB ?

It is ready; this time in csv format too :p

Nice :) Although all my parsing code is now useless I suppose. A negligible sunk cost.

It would be more useful to have list of search engines (ideally working via tor too) for papers where anyone can get results for any keyword (not only monero)

Do number already allow to speculate about the final overall speed of "Monero on Seraphis"? Will it sync the blockchain slower? Much slower? Faster? Will wallets scan faster? Etc.

Good thing I ran into parsing issues or it may have taken more time to realize that bug exists.

*numbers

hah yeah 1 in 600k cases...

rbrunner: it should allow relative comparisons of blockchain sync times with different parameters

wfaressuissia[m]: I would prefer a shared repository for the papers, or the abstracts of the papers at least.

Wallet scanning is a separate issue

I see. But maybe the speed comparison with Monero as it is now will fall out of this as a by-product? Maybe not.

Yes it should allow comparisons with current Monero

Since I collected results for CLSAG

Ah, interesting.

CLSAG after BP+ and ring size 16*

This is very interesting. Link?

So it might show soon which the direction things will take.

... and useful

ArticMine: github.com/Rucknium/misc-research/t…main/Monero-Cryptography-Benchmarks I think Rucknium[m] will upload the latest data at some point.

ArticMine: Old (pre-bugfix) data is here: github.com/Rucknium/misc-research/t…main/Monero-Cryptography-Benchmarks

Bleeding edge research :) Even the stats have bugs ...

rbrunner Monero code had bugs, not the stats :p

This one: monero-project/monero #8052

That was enough to affect outcome? Surprising.

The issue was that extremely rarely the verification would fail, so the results would not be output. And the failure mode made parsing difficult

Thanks

How about: "Seeing a bug in Aeon transactions where multiple inputs in one transaction use the same output. " monero-project/monero #8047

It's not really a bug. It's just how things work now. The question is whether there are any costs or benefits to trying to avoid these "collisions".

This seems to be a consequence of small rings, but the privacy hit is not as big as the fact that the rings are small anyways

The collisions would seem to happen much more often on Aeon rather than Monero since Aeon has much fewer transactions and therefore fewer outputs to choose from in a given time window.

It makes the implementation simpler when there are few outputs in the chain (just after hardforking to a new epoch).

You should look at the rings on Monero testnet, where we have fewer txs still. Sometimes they look *really* funny. But I can't see how that matters.

Wait, under what circumstances would the decoy selection algorithm not be able to select outputs from before a hard fork?

Any privacy hit would be dependent on external data. E.g. if the duplicated decoy is a known spent output, then you lose 2 decoys instead of 1

I believe that happened when RingCT went live. It will also happen if Seraphis goes live.

It happens when you need to transition for some reason. E.g. transition to hidden amounts, or transition to a new key image construction.

Oh boy, more statistical issues to dive into!

Er ... and the very first new txs have nothing at all to select as decoys?

Interesting. Maybe we should organize users to spam the network with churned transactions at the upgrade time?

It seems strange since old genuine outputs can be spent.

if there would be any advantage in doing this activity then any attacker could do the same, so it's useless

this system should work independently from any users actions

When old outputs get spent, the new outputs in their tx are 'in the new format'. Also, new coinbase outputs are 'in the new format'.

So some of the ring members would have the old format and some would have the new format. It seems that decoys could still be selected from before the hard fork, right?

No, rings can only have outputs with a single format. So all new outputs would be in 'new format tx'.

So when you spend a very old CLSAG output, it will be obvious that you are doing so? Because of no recent decoys selected

Ok. So there would be a mix of old-style and new-style. Um, let me get this straight...

Correct

This is an unavoidable engineering problem.

Well, still not clear how long before the hardfork that old output came into existence, right?

s/unavoidable/unsolved

[old,old,old]-->[new] , [new,new,new]-->[new] would be allowed after the hardfork

[old,new,new]-->[new] , [old,old,old]-->[old] would not be allowed.

And that it's CLSAG is obvious anyway

Rucknium[m]: yes

I think preventing duplicates is the technically correct thing to do from a stats perspective. In the tx sanity check, it first checks if there are >10k outputs available to use before checking there is only a small margin of duplicates. Could do something like that in the wallet to avoid challenges around fork time to a new format

UkoeHB: Ok. There are many thorny statistical issues in such a hard fork, then. We can research how to have a smooth transition.

How would the decoy selection look like when spending an old clsag output? Would it still follow the usual distribution (just traslated to older blocks), or would it change?

merope: that sounds like an _open research question_ :)

Hehe

UkoeHB: Yes, that's what I'm saying. Needs study.

Random thought: there should be a stroger bias towards older outputs after a while, because otherwise the last clsag outputs will show up in multiple conversion transactions, while the older ones would show up only once at most (ie when they actually get spent for conversion)

(Just throwing that in open)

I guess we could look at the pre-clsag to clsag conversion txes for reference

Looks like a whole new can of worms opened today.

Wouldn't all the CLSAG outputs eventually end up in the long tail of the distribution? So little difference between older or newer CLSAG outputs

merope it would be pre-ringct to ringct

Oh right

rbrunner: I agree. Yum! Tasty research worms! 😋

we could analyze older data of known spents too, but ignore the X most recent outputs at any point in time, and look at different values of X

Before we close, I would invite everyone to think about what an independent funding mechanism focused specifically on research could look like, and maybe post your thoughts in #monero-research-lounge:monero.social

hmmm, in this case, maybe it makes sense to "throw away" the portion of the gamma curve (or whatever curve is used) that is unrepresented. So as you move further away from the fork height to a new format, you start ignoring a larger and larger portion of the curve that is more recent

Is that doc still private ?

wfaressuissia1: what doc?

rucknium[m]: your document ...

My HackerOne submission is still private. I edited the language on disclosure in my CCS proposal recently.

The "Document A", i.e. OSPEAD technical specification, is still getting feedback, and I hope to push out a public version within the next week.

Ok we are at the end of the hour. Thanks for attending everyone.

also update from me: initial view tag implementation is finished, working on finalizing tests at this point. Sorry the daylight savings time switch messed me up

How would you test new mechanism for decoy selection without any tools written by mj-xmr ? Are there no open source alternatives ?

rucknium[m]: for you

wfaressuissia[m]: Yes, there are a million open source alternatives. One of the main benefits I get from using mj-xmr's tools is that I have another time-series-oriented person to bounce ideas off of.

My research can proceed without use of mj-xmr's tools, but they are nice to have.

<jberman[m]> "also update from me: initial..." <- Same thing happened to me.

Has there been any research done on homomorphic encryption for chain sync?

yanmaani: probably no

i imagine there's no way to avoid it being O(n) over the history

Not without privacy losses (eg using an ‘account’ model instead of ‘txo’ model).

UkoeHB: I mean, can't ElGamal for example do multiplication of two ciphertexts?

a*b*c*d*e*f = 0 if any of those are 0

and decrypting random data gets you (except with negligible probability) non-zero, right

so if each transaction had a field with encrypt(0, viewkey), wouldn't that enable you to do this, with the right cryptosystem etc?