What was the characteristic of transactions that revealed whether (a) all outputs were sent to primary addresses or (b) one or more outputs was to a sub address?

Was it some field in tx_extra?

Yes. Whether the extra tx keys field is present.

BUT if it's just one subaddress, it's not present and the main tx key is used.

So the distinguishability only occurs for txes with > 2 outputs.

And there's some slight space wastage for these.

What do you mean?

Either more data than needed, or being thrown out the airlock. You get too choose the one you prefer :)

Oh do you mean we could theoretically use the main key for one of them, and include N-1 extra keys?

Yes, or remove the main key.

Research meeting here at 17:00 UTC (about one hour from now)

good morning everyone

hey

Happy Festivus to everyone

who has grievances

Who doesn't.

Until you pin me, suraeNoether, Festivus is not over

sarang instead of calling CLSAG concise or compact or any of the other great suggestions folks have mentioned, i think we should avoid giving it a name in the paper and rename the paper "Ring signature size reduction by key aggregation" or something boring

we can call it clsag in our code, who cares

but the reviewers are going to be annoying i can tell

We could do that

Just say we're giving a construction of a d-LRS

since really the idea of d-LRS is what we're producing

Key-aggregated linkable ring signatures and applications

It'll make the narrative more verbose: s/CLSAG/our new signature construction/

ehmmmm maybe. don't make any changes yet

i'm going to be reading

I won't make any changes

IMO the name is not that big of a deal

If anything, maybe just change the title

and/or remove the CLSAG naming from the abstract in favor of simply saying that we produce such a construction that gives better size efficiency and (for some ring sizes) better verification times

I'll make a review comment in Overleaf for this, so we keep it in mind

better over naive methods that also haven't ever really been proposed before :\ heh

except in ringct

Better than methods currently in production that don't use trusted setup

"Thanks to the helpful comments from our esteemed reviewers, we rename our construction to Cranky LSAG"

Cool LSAG

Or recursively define the "C" in CLSAG to stand for "CLSAG"

Research meeting beginning in here in 2 minutes

although we'll stretch the intro greetings to catch stragglers

allright, everyone, welcome to the MRL weekly research meeting

Hello

Happy Festivus!

hello

agenda is here: monero-project/meta #422

we'll start with GREETINGS. hiya!

mele kalikimaka, etc

let's move along to the ROUNTABLE

i know isthmus has been up to some interesting stuff with block sizes and fees, but he doesn't appear to be here. sarang, as usual, has been busy. you want to start, sarang?

Sure

I redid the CLSAG linkability and non-frameability definitions, theorems, and proofs

and then did a major reorganization of the preprint for clarity and style/format

It's ready for suraeNoether's review, and then posting

Additionally, the Triptych preprint draft is ready for suraeNoether to review as well

and then it can be posted

good times

word, word

does anyone have any questions for sarang?

Apparently not!

I have a question for the MRL team regarding L2 scaling for Monero: Are there any scalability solutions currently deployed on Monero? If not, why not?

I assume you mean off-chain?

I do mean off-chain

not currently deployed. DLSAG and thring signatures are two fundamental pieces of off-chain scaling

DLSAG is currently... uhm... accepted for publication? did iirc?

Accepted to FC2020

that's a spicy meatball, yes

Awaiting some likely rewrites for definitions

Downside is that indistinguishable refund-compatible transactions don't play nicely with key image requirements

mikerah[m]: requires some more research into how to ensure consistency in key image use

^

So, the current state of the art for monero is DLSAG, thring signatures and the Tari sidechain?

tari sidechain is independent

Tari is a separate project

but built on top of monero, from my understanding

No

er... sidechain

not *on top of*

IIRC they're doing a MW-based implementation

oh

news to me *shrug*

Hoping to do merge mining

But I have not been following their recent work

ah

<suraeNoether "news to me *shrug*"> Me too. I guess the association to fluffypony made me assume that it was Monero related

well, for my part of the roundtable, my work this week was to start copy-editing triptych and clsag, and to work on my matching simulations. I just made a push this morning... github.com/b-g-goodell/mrl-skunkwor…ks/tree/matching-buttercup/Matching

anyone can run tracing.py and it will create a data folder, stash human-readable simulated monero transcripts inside...

mikerah[m]: to be clear, DLSAG is not deployed anywhere

<sarang "mikerah: to be clear, DLSAG is n"> Thanks for the clarification.

these transcripts say things like "Alice sends key NODE_ID with ring members RING_MEMBERS, authorizing the creation of outputs NEW_NODE_ID owned by Bob." It's a "ground truth" ledger.

these transcripts also contain the accusations that Eve makes. "Eve thinks ring signature NODE_ID belongs to Bob. In actuality, it belongs to Alice." sort of thing

in theory, anyone can fire up tracing.py, tweak the parameters inside, and see the simulated ledger

the ledger is working just fine

nice

unfortunately, but also fortunately, once i put these transcripts into human readable format it became immediately obvious there was a problem with my Eve

she is allegedly granted knowledge of her part of the graph, but she doesn't incorporate that knowledge into her matching solution appropriately.

so the previous numbers i shared in here, which i took care to explain where provisional, are lower than what we can expect from a realistic eve.

these problems were not being caught by my unit tests

What needs to be done to properly account for that?

the run_experiment function in tracing.py builds a dictionary called eve_ownership, which is not utilized correctly, and allegedly deletes spurious ring members, but i have some evidence that this isn't being done correctly either

what really needs to happen is that eve builds a sub-ledger by deleting all her known information, so that it's purely "uknown" data to Eve, before playing the matching game

that, together with reporting her known information, would fix the problem

since i have CLSAG and triptych to take care of, and since so much of this code is human readable at this point, i'm putting this project down until the new year

especially since "the problem" is easily explainable and I can point to where it's occuring

but, for example, if anyone wants to just simulate a ledger using different stochastic matrices or spendtime distributions, they can tweak the parameters inside of tracing.py and generate as many ledgers as they like

and now you can read them like a story. the world's least interesting procedurally generated story.

i'll be unavailable for the next 72 hours or so (family is coming into town) but i have CLSAG and triptych printed; i'm about 1/3 of the way marking up my copy of triptych

that's all i have today. does anyone have any questions for me about that, or other questions on anything research-y?

When you're done with Triptych, will suggestions be added as Overleaf review comments?

i was going to add some as comments and send the rest as an email to you

Great, thanks

You have the line-numbered version?

yep

okay, let's move onto ACTION ITEMS

sarang?

I'll be addressing some multisig-related MPC stuff for RCT3 and Omniring

Then working on any necessary updates for CLSAG and/or Triptych based on review

and then getting both papers posted to IACR

Helping sarang finish triptych and clsag; if i finish this before end-of-year, i'll go back to matching

Oh, a longer-term action item is to backport the CLSAG security model changes to DLSAG, but that's likely not this week

I don't recall the DLSAG reviewers mentioning it, but it should be done anyway

allrighty

unless anyone has any final quesitons

i think we can adjourn

Happy Festivus!

Hai

Just in time =p

I’ll still be working on block sizes and fees

Anything in particular of interest?

I had a lightbulb moment last night for a retrospectively obvious way to subtract txn fees from block payouts. So lll deconvolute the two and report here. Otherwise I’ve been digging a lot into Zcash and finding out that they have a lot of the same problems Monero encounters/Ed

Zcash uses a fixed wallet default fee, right?

and no particular consensus rules around fees?

Kinda, it’s implemented in the wallet but not protocol

right

Might write a general book about designing private decentralized ledgers from a statistician’s perspective, now that I see the common issues

Meaning there's no size/weight dependence, which was pointed out a while back by someone as a possible DoS vector

(this was publicly stated already)

DoS or bloat

Former has been publicly noted and discussed

Yeah, IIRC the idea was to include a bunch of shielded outputs that required nontrivial scanning or something?

For the DoS, yes

The miners also accept 0 fee txns

roger

So you can stuff blocks for free up to 2MB/75sec

Is that the current block time, or the post-upgrade expected time?

Er wait, they already upgraded

nvm

-_-

I posted some Zcash plots in #noncesense-research-lab and will probably update them today

Are there plans to address this via defaults or consensus rules?

Anyway, sorry, I derailed your earlier mention of deconvoluting fees

I brought it up during a meeting with the ECC and it was on their radar and to do list, but there is not consensus on how to move forward

Ah fees stuff will be more interesting in a few hours when I generate payout-only plots

*coinbase-only

Nice!

I think Zcash <> bloat is like early Monero <> Big Bang conversations in that they’re thinking of it as a future scaling problem but it’s literally something I could induce today

:- /

This principle will be a chapter in my design book, lol

I'm surprised they don't have plans to address, given that the fee structure has DoS capabilities as well

I think you can’t have fixed fees and a fixed block size

One or the other (or neither)

It's certainly true that given a large enough transaction volume, you couldn't have a fee market anymore

How many Zcash blocks have approached the size limit?

Let’s close out the MRL meeting and reconvene in about an hour? I have a few meetings coming up but will loop back with plots ^_^

Lots of interesting features and anonymity puddles

Oh, the meeting was already closed

not that it really matters

Oh good, I didn't really want to go on the record rambling about preliminary Zcash results anyways.

got it

Certainly interesting, given all the past discussions about block sizes and fee models

What would be an example of something that would be discussed in a meeting?

It's just a short time set aside for anyone to share interesting research they've been working on

Quite informal

I can't really imagine what it would be like though

See meeting notes: monero-project/meta #422

I didn't understand a single thing reading that :)

Happy to answer any particular questions

But thank you for giving me an example of what it's like

I mean, I would question the whole thing and it would take forever

Like what is Triptych

A linkable ring signature construction that has good scaling properties

still work in progress

And what is a linkble ring signture construction :)

permits signing on behalf of a non-interactive group, and lets verifiers know whether or not the (unknown) key has signed before

The keys in this being tied to hosts running monerod?

Keys used in such a signature are previous transaction outputs

:\ How often does matrix do that?

Reasonably often, it seems

sarang: you're correct, Tari is MW "on top of" or "on the side of" Monero

dependent on how you want to view merge-mining + atomic swaps

They using ristretto?

yes

we had it audited

How are you doing atomic swaps ?

moneromooo: nothing set in stone, as yet

nothing spectacularly new in the RFC, but there it is

moneromooo: did you see Fireice is working on atomic swaps for Ryo? i.e. cryptonote base layer. But I saw no discussion re privacy implications.

What is MW?

I saw a mention. I'm trying to keep my life fireice free though. Every time I did not, I ended up regretting it.

MW is mimblewimble.

<3 dalek is Rust

Yes it is, and well designed

I was just reading the link and surfing from there and discovered it.

Ok, sorry I got pulled away from the meeting for another meeting

What was it somebody asked?

Ah yea "@sarang: How many Zcash blocks have approached the size limit?"

There's a stretch from 200000 to 350000 where a bunch of blocks were around the 2 MB limit

(At the same time of many 2 MB blocks, there signal is weakly echoed at the 1 MB mark, which makes me suspect a pool with something like 10% of the hashrate mining via software that still had the old BTC 1 MB limit hardcoded in.

)

*their

Argh, I need coffee

thanks Isthmus