<[keybase] unseddd>: pong sarang

I haven't run local fuzz tests before (shame on me) and I'm getting an error asking for an input file

The gen_corpus flag is being parsed as a filename

wat do unseddd

(this is for your CLSAG fuzz PR)

<[keybase] unseddd>: what's up?

<[keybase] unseddd>: hrm, maybe I checked in a previous version of the test... my bad, will fix and push

<[keybase] unseddd>: idk what the problem would be. does not happen on my end. will do a fresh pull, and try re-running the test

<[keybase] unseddd>: sarang: I am dumb, wrote `--gen_corpus` when it should be `--gen-corpus`. doc error...

<[keybase] unseddd>: let me know if that fixes it for you

unseddd: please update the CLSAG fuzzer to integrate with moneromooo's fuzz shell script runner

<[keybase] unseddd>: sure, was not aware of the fuzzer script. will take a look after the meeting

Meeting here begins at 17:00 UTC (about 10 minutes from now)

OK, let's get started with the research meeting!

First, GREETINGS

hi

hi

<[keybase] unseddd>: o7

hi

Let's go ahead and continue with the ROUNDTABLE

Anyone is welcome to share research topics of interest

I suppose that I can share a few things

Relating to timelocks, I extended CLSAG and Triptych to support them

CLSAG: SarangNoether/monero 28f0982

Triptych: SarangNoether/monero ed48ab1

Here is corresponding timing data: usercontent.irccloud-cdn.com/file/dQXuFH2U/timing.png

3-CLSAG and 3-Triptych are the timelock-friendly data series

The other data series are unchanged from when I first shared them

I suspect that 3-CLSAG could be optimized by perhaps another 10% or so from what appears on the plot

Unrelated to this, I'm updating how in-memory key encryption is handled, which is taking a bit longer than expected

and am reviewing the new CLSAG fuzzer tool that unseddd provided

That's about it from me!

Are there any questions that I can answer?

Nice work

Thanks!

CLSAG optimization in verification time, size or both

<[keybase] unseddd>: seconded, nice stuff sarang

ArticMine: in verification time, and only for the new 3-CLSAG variant that would apply to encrypted timelocks

Great work by the way

Thanks

When I wrote 3-CLSAG, I used a particular multiscalar multiplication that could likely be made faster for this particular case

Also, huge thanks to unseddd for reviewing CLSAG and writing the fuzzer tool

<[keybase] unseddd>: is 3-CLSAG limiting the multisig to three parties?

<[keybase] unseddd>: np :)

No, it adds another key component that would be used for timelocks

Right now we have two key components: one for the usual signing, and the other for balance purposes

<[keybase] unseddd>: ah, thanks for the clarification

Does anyone else wish to share research of interest?

it seems like 3-triptych would reduce the ringsize likely to be selected by a power of 2

<[keybase] unseddd>: not much interesting on my end. just reading formal verification papers + some pq-crypto stuff from Mike Hamburg

Adding encrypted timelocks is a nontrivial verification hit

What is the time ans size cost

What might be interesting as an alternative would be to allow cleartext timelocks, but update decoy selection to account for known spend patterns

It would not eliminate fingerprinting, but could help to mitigate age-related selection heuristics

<[keybase] unseddd>: are there any leakage issues having the timelock in the clear?

ArticMine: going from CLSAG to 3-CLSAG is about 1.4x increase in verification time

Which could probably be reduced slightly with some extra work

In terms of size it's fairly trivial... adding an extra auxiliary key image (this does not account for other non-signature data)

unseddd: for sure

I'm not saying that I advocate for such an approach, only that it could be an option

and would not imply any size/time hits

it's a ways down the road, but I'd like to mention it now; when deciding ring sizes for next gen tx protocol I feel it should be based on a broader analysis of theoretical maximum tx throughput of the network; this is because the max tx volume is when rings are _least_ useful to defend against non-scaling graph heuristics, and because larger ring sizes actually reduce the max tx volume; it's an optimization

problem

<[keybase] unseddd>: right, from a naive perspective, triptych seems like it has enough savings for the hit from timelocks

sorry I'm late. catching up

UkoeHB_ The maximum tx throughput is also dependent on external factor tat keep improving over time

unfortunately that optimization depends on the efficacy of ring sizes.. which we don't have a complete understanding of; I hope suraeNoether can return to that topic at some point

ArticMine: true, there are a lot of factors to consider!

At the very least, we now have concrete numbers for the spacetime effects of ring size increases

hi

the cost of encrypted timelocks seems extreme to me tbh. I don't want to go there unless we know we need to support them for a good use-case

Getting timelock-related spend age data from transparent chains might be helpful if it's decided to continue to allow cleartext timelocks

Then output selection could be improved to account for it, and reduce the usefulness of spend-age heuristics

<[keybase] unseddd>: use-case: timelocks necessary for atomic swap, encrypting is the most private

<[keybase] unseddd>: could also see the counter-point for clear timelocks if they are necessary for atomic swaps (interop w/ clear chains maybe)

sarang: I agree, but given the current low utilization, I consider this low priority. The impact to the wider network is negligible

Payment channels come to mind here

also escrow

if there's a payment channel, then we can move to make encrypted mandatory. when that happens

Getting that kind of transparent chain data seems pretty straightforward

@sarang, it's on my to-do list for XMR and BTC

:D

How do you plan to examine spend-age data for XMR?

It was examined in Miller for "deducible" outputs (pretty sure that's the term they used) that were the result of chain reactions, which we find don't occur anymore

Oh, I just meant comparing the unlock time height to block height to see how many of them even make sense

Not that current usage tells us much about future applications.

Ah, got it

What is it that you were interested in?

Isthmus are you thinking about atomic swaps these days at all/

@sarang sorry I'm in a zoom call and IRC meeting at the same time, and missing little pieces of both

I'd like to see the age distribution of spent outputs in a transparent asset (like BTC) relative to lock expiration, to see if it differs substantially from the overall age distribution

No problem Isthmus!

ahhh, yea I can't officially do that for Monero yet. I'll pull it for BTC though.

can't officially? it's possible?

Thanks! The overall distribution likely is still similar to the Miller data

(for BTC, of course)

and having that data would be an interesting check of that

@UkoeHB_ yeah, I mean my research over the past few years reveals anonymity puddles covering like 20% of transactions. Then change outputs bleed everything, so there's a ton of data on obviously real spend times. BUT no guarantee that it's representative.

I'll be supper curious to see the BTC distributions, will try to get that in the next week or so.

*super

Yeah, Miller's team used two different large sets of blocks in BTC for their analysis

and found the distributions to be similar

but it doesn't appear they accounted for locks

OK, did anyone else have a topic to discuss?

Insight is interested in researching practical post-quantum cryptography for Monero, especially privacy features that will remain secure against retrospective deanonymization by future adversaries that can utilize Shor's algorithm, Grover's algorithm, etc. I want to know what our options are, and their costs (complexity, proof size, generation/verification time, etc)

Looking for feedback on the research plan.

Our goals are to (1) study and simulate the threats listed above to assess vulnerability to quantum computers, (2) evaluate post-quantum cryptography scheme candidates to create a roadmap for hardening Monero against quantum adversaries, and (3) provide open-source proof-of-concept code and demos where applicable.

<[keybase] unseddd>: i like pq stuff :) will take a look

Sounds like a fascinating project

I'd be very curious to see what exactly the Phase 3 deliverables would look like

Me too! ^_^

and I think it'd be important to assess any transtion points between constructions/protocols

e.g. it was possible to transition from pre-CT to post-CT

Yeah, we'll have to document both the transition and post-transition costs/tradeoffs

New constructions are great, but if it's not possible/feasible to transition on the same chain, that's a sticking point

<[keybase] unseddd>: here is the Hamburg paper i am reading through: shiftleft.org/papers/qromcca

Yes this is a very interesting project

Are you confident about the timeline?

Particularly surrounding the Phase 3 stuff

(not that practical quantum computers are expected by the end of summer...)

There's two types of things we could prototype

it does say May - June, only a couple days away, not sure if a CCS could be approved and funded in time

<[keybase] unseddd>: ten million qubits by fall!!!

(1) demo of a quantum computer breaking a Monero encryption feature (at a reduced keysize, or something like that)

s/June/July

Adam did this before, got an IBM quantum computer mining bitcoin at shorter hash length

So that's demo breaking classical crypto

(2) prototype a possible solution

(so we'd use traditional computers and prototype a future solution)

<[keybase] unseddd>: _thoroughly impressed_

Now honestly, I think that #2 would be way cooler. But it also may be hopeful thinking

I've seen Adam rapidly convert math papers to code before, but this is going to be a pretty serious endeavor

Either way, would be fascinating

here was my note in the writeup

"Phase 3 deliverables: The best use of time during this final stage depends strongly on results from the exploratory research. Likely deliverables are a proof of concept or prototype tooling for demonstrating a vulnerability or potential solution"

would (1) also include a comparison with a classical computer on the same task? at reduced keysizes, the encryption is weaker on classical computers too

<[keybase] unseddd>: Isthmus: are Adam and you regularly in IRC? what is best communication channel?

@UkoeHB_ exactly

Adam'll be on IRC shortly :- )

We'll probably do a lot of the research in this room, if that's okay with people?

Or could make #pq-mrl

Up to you!

👍

OK, any other topics to address before finishing up the meeting?

does anyone have new thoughts on monero-project/monero #6456?

<[keybase] unseddd>: UkoeHB_: unfortunately no, have been consumed elsewhere. many apologies

UkoeHB_: I got unexpectedly caught up in other coding, and didn't review in detail yet :/

Oh! Yeah, I'll look at that by Monday. Hopefullly today

my aopologies

s/aopologies/apologies

All righty, any ACTION ITEMS for the next week to share?

I will be reviewing 6456, reviewing some CLSAG tests, updating some in-memory encryption code, etc.

I'll probably bump the pq-monero proposal over to CCS by EOW, so shoot me a message (irc or isthmus⊙go works) if you have any suggestions for updates or additions

on a certain level I have nothing else to contribute to the proposal; whether it gets implemented or not is out of my control; keep in mind it likely won't be superseded by anything, so for 'tx extra', 'janus mitigation', 'tx pub keys', and 'view tag', that's the 'final answer' for the forseeable future

I'm working on some slides (summary) that details how Grin does their grin-btc atomic swap

looking to see if we can get some insight for xmr-btc swaps

Iǘe become convinced that itś never in any XMR holders'interest to swap for BTC, due to BTC taint issues

but I'd be curious to see how it can work, for future XMR(earth)/XMR(mars) swaps

<[keybase] unseddd>: hyc: even for true DEX scenario?

<[keybase] unseddd>: marsero

especially for true DEX, wher eyou can't vet the BTC

the benefits are all one-sided, in favor of the BTC seller

Eh if I've got a wallet full of Monero, but the sandwich shop I'm standing in only takes BTC, I might find that swap useful.

I have to agree with hyc Selling XMR for BTC on a swap is very dangerous

<[keybase] unseddd>: yeah, i see your point. do you have the same opinion for other swap pairs?

if the other pairs also involve transparent coins, yes

+1 concern here

Well, in the interest of time (our hour is up), I'll adjourn the meeting for log purposes, but discussion can of course continue

i still think swaps for dex is better as currently many use centralized exchanges for xmr-btc swap

<[keybase] unseddd>: thanks for the meeting and lively discussion :)

I don't really understand the benefit of swaps, since you can already exchange xmr/btc fairly easily

I think in the case of BTC it's safer for users to use centralized exchanges

who guarantee the BTC you receive is clean

true UkoeHB_

hmm good point

there may be other coins worth swapping with. maybe zcash if they every migrate to z-only

<[keybase] unseddd>: atoc: i agree with you. while xmr-btc is riskier from a "might-be-dirty" perspective, atomic swaps are a practical improvement from a trust perspective

btc-xmr atomic swap is a research topic which is why I have been investigating

and yeah hopefully it can be applied to other coins

<[keybase] unseddd>: the protocol could also include built-in taint analysis for "dirty" coins

ah that's an interesting idea

as far as btc-xmr in particular we should note implications you describe

the only swap I'm interested in tbh is XMR/zZEC

if you actually *can* screen the BTC before the swap commits, that could be ok

hmm that would be interesting

What about BTC coinbase <> XMR swaps

BTC coinbase, maybe

idk how that screening algo (taint analysis) would work

hm, that sounds ok

and hopefully there are no false-positives

yeah that's good

atoc: it would be terrible unless you pay for a "big three" blockchain analytics firm (and perhaps some smaller ones)

Isthmus

taint analysis requires blacklists or oracles, so coinbase-only is the only way I can think of to do it a priori without centralization

would swapping to XMR automatically taint coins? is a swap identifiable?

taint is in the eye of the beholder

Isthmus: sure, but....... not really

good question UkoeHB_ and yeah Isthmus lol

<[keybase] unseddd>: atoc: no idea how it would work either (not a chain analyst). but those c*nts have some algos that work, so we could repurpose them for good ;)

UkoeHB_: it might taint the BTC

well using a mixer already taints BTC so I imagine xmr<->btc would too

Hey @atoc - circling back to earlier. I haven't thought about atomic swaps much but I'd be happy to :- ) What are the interesting questions there these days.

@unseddd indeed

I would guess you can't hide that it's a swap txn on the BTC chain

we are currently trying to use this implementation

or rather

get an implementation for these ideas by h4sh3d

we are missing ideas for a general zkp that proves the pre-images of discrete log groups

well there are some ideas

however we need to try and see if they work

Grin claims to have successfully done a grin-btc atomic swap in a similar fashion along the same lines

so right now I am looking to get a better understanding of their implementation

and see how it could work for xmr-btc

<[keybase] unseddd>: xmr-grin-btc could create some interesting tx-flows

I'm iffy about even xmr/grin

<[keybase] unseddd>: (derp thought, not serious)

discrete log groups equality (ideas of @andytoshi, documented by @sarang) here: web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf

has useful ideas for this as well

@unseddd hmm that would be interesting

I haven't considered that

<[keybase] unseddd>: lol mb, think it would be funny to see an analysts face, like "wtf is even happening?"

hopefully that gives an idea of current questions Isthmus :)

presumably after you solve it for XMR-BTC others will follow easily

yes this is what I am thinking about grin-btc

it seems they have a relatively general approach

@unseddd yeah lol

<[keybase] unseddd>: think i will follow Isthmus out the room. thanks again for such a cool conversation

yes thanks everyone

.time pdt

11:16am

pretty shit timezone lookup

.time pst

one last try....

.time `ls`

.time est

it's not including daylight savings i guess.. off an hour... anyway /spam

btw what's the story behind monerobux

is this bot opensource and worked on by the Monero community?

cool feature

jwinterm is author, I believe

ah nice

I invited it to help with time, substitutions, etc.

My favorite color is green

s/green/blue

lol

but as you might guess from the name, was originally written to give us coin stats in the -markets channel

i like the meant to say feature

lol

s/meant to say/bux

s/`/\\/

I guess once you get atomic swap working, screening could be an extensible addon

first default screener would be "coinbase coins only"

users could opt to set "any coins, except blacklist at foo.bar.com"

yeah - that would be good

You dont' want to refer to outside resources for consensus.

yeah whitelisting and blacklisting servers is useful too (similar to email feature)

is this consensus? I think this is a mutual choice between the two swap parties

Alice can abort the txn if she doesn't like the BTC Bob is offering

Depends how it's done I guess. I was imagining Alice puts up a partial tx, which Bob can then fill.

well typically you only want to abort if something went wrong

i guess this could be included in some exception

if it's done how moneromooo suggests then it doesn't need abort

rather wait for the correct criteria

aborting results in some loss (to account for fees)

atoc, not exactly, it is based on sopel irc bot, which is based on willy irc bot

I mostly added price and network and silly commands

The bot is in #monero-research-lounge now too

jwinterm nice

how do we get price?

Please do not use this channel for price stuff

yea, join #monero-markets or #monero-pools for other stuff