i think an interesting consideration when it comes to our cost benefit for ringsize / time / space

-

if we deem it necessary to increase the ringsize, then it would have been necessary regardless of the current technology providing it.

for instance, with that recent image, if a ringsize of 2^5 is deemed necessary, then the actual comparison point would be there MLSAG would put it

thus, putting the triptych numbers into anonymity set size of holy cow

off the carts

charts

some words in there can come and go.... but you get the idea

i feel like , at least for myself, one way of looking at it was "well, MLSAG currently puts us at this, so with triptych we can get this at that cost"

but perhaps not. because if we deemed this (the second this) necessary, then we would have done it regardless of the cost (perhaps)

eh i shoulda prolly gone to the lounge for this

bouncer!

which i feel like boils down to the question of how many rings is enough, which is statistics i guess, of which im not a fan.

well not rings, but members

Reminder that the weekly research meeting is today at 17:00 UTC (about 2.5 hours from now)

.time

good bot

.time

Do you have to start the message with .time

.time apparently

Not what I was expecting

Oh, I bet it can provide the time in different locations/timezones

.time utc

.time utc+4

.time us/pacific

.time pacific

Oh well. We'll start the meeting in about 5 minutes or so

OK, let's get started with the meeting!

.time PST

First, GREETINGS

hi

Hello

.time localtime

.time cdt

First agenda item is trolling the monerobux bot

naturally

Well, let's move to ROUNDTABLE

ooh

Hi

I assume Isthmus would like to share the material he posted on the agenda issue?

Specifically: monero-project/meta #456#issuecomment-617883059

Sure

Go ahead!

hi

Just completed a study quantifying the impact of exchange rate volatility for Monero-denominated delayed payouts.

Normally I consider exchange rate stuff out of scope for MRL but this is relevant to all CCS-funded contributors

Hm, I was going to cut and paste from the GitHub issue but everything is slightly too long for IRC

Basically, I put together a sliding window statistical analysis of the XMR price timeseries to create a framework for volatility risk management

The TL;DR is this:

[INPUTS:] X% confidence that a Y-month payout will cover the quote (based on the last Z months of data) can be achieved with an [OUTPUT:] V% volatility buffer.

Suppose we want to look at the last 24 months of data

And consider a 4-month sliding window (1 month to fundraise on CCS + 3 months to execute)

Here are the outcomes based on historical data

We observe an unfortunate asymmetry over the past two years, for example: contributors to projects with a 4-month timeline were more than twice as likely to experience a 50% decrease in compensation value (red line) than a 50% increase in compensation value (green line).

That's quite the asymmetry

That's the probability distribution function, the cumulative version is helpful too:

The red cross highlights that USD/XMR decreased over 65% of sliding 4-month windows (i.e. only 35% of contributors would receive payouts worth the quote price). The orange cross shows that an 80% likelihood of receiving a sufficient payout would be achieved with a +35% buffer.

Explaining the orange cross in the framework described above: 80% confidence that a 4-month payout will cover the quote (based on the last 24 months of data) can be achieved with a 35% volatility buffer.

Now, let's consider what happens if we double the timeframe (so that the data include a bull market as well as cryptowinter). The previous plots spanned the last 2 years (blue dots); now let's extend this to 4 years (blue & green dots).

oops transparent background, ssorry

Now that our we include both the bull run leading up to the all time high and the subsequent decay, the extended data set contains new outcomes on both sides of the red breakeven line (+ a few outliers omitted on this plot that are shown in the next).

Over the 4 year history, we see that about 60% of the windows receive a payout covering the quoted value (red cross). Since the data set now includes an 8x bubble in its entirety, the volatility insurance rate for 80% confidence rises to a 170% buffer (orange cross).

I'm hoping that having a volatility risk management framework like this will increase funding accessibility for people/businesses that want to contribute but cannot afford speculate on income.

This is great data

Any questions for Isthmus?

Volatility is expensive

No questions, but thanks for doing this

ty :)

I can share next, if there are no other questions for Isthmus

More of a comment.

Thanks for the work

Yeah thanks, just for more clarity: what are Monero-denominated delayed payouts?

What we are dealing with is more like a two bear market as opposed to volatility

It seems like long delays in payouts are not worthwhile. Either donators or donation recipients will lose on fiat-equivalent purchasing power with a good probability

With the bear trend longer than the term of the typical CCS

ah I see what this is now

I actually wondered about this previously too. This is definitely good info

Donators can't lose. They get exactly what they intend in terms of exchange rate. Recipients can lose or win. Other market participants (which could also be the donators or recipients if they choose to play the markets in the meantime) will win or lose.

Donators can lose if recipients justifiably ask for premiums in the name of volatility, so donators are paying for the volatility

At any rate, it provides useful information for proposers and potential donors to assess the impacts of volatility

Isthmus: did you want to also discuss TheCharlatan's possible work on timelocks?

(you just posted to the agenda on it)

I think volatility is the wrong term here

@ArticMine yeah, there may be a more precise way to phrase it. Let me know if you have ideas

@sarang sure

We discovered a few months ago that Monero's plaintext unlock time leaks information and presents a transaction linkability risk

An encrypted unlock time is possible and would solve privacy issues, however the design and performance characteristics must be carefully considered.

Right

The issue is a systematic downward trend during the term of the particular CCS

We investigated this with the DLSAG preprint

Insight has put together a proposal for Isthmus & TheCharlatan to research solutions over the summer. Looking for feedback on the plan here: github.com/insight-decentralized-co…us-lab/monero_encrypted_unlock_time

Our goals are:

The method from the DLSAG preprint works even without the dual-key output structure, and I have some code demonstrating both the general method and how various LRS constructions could be used for this

Detailed system design decisions (e.g. unlock_time per output or per transaction?)

Prototype code to quickly test different approaches , including simulating transaction construction, signing and verification

Report of quantified space/time/privacy tradeoffs with each mitigation strategy

Implementation code for Monero source tree, for at least one of the chosen approaches

Comprehensive research analysis writeup , cross-referenced with code and documentation

Oh sorry Sarang, go ahead

Oh no, just providing some background; please continue

Oh, that was the end of the list :- )

Ha got it!

Yeah, so there was already some work on this

and I've been discussing it with TheCharlatan

Basically you can follow an approach similar to that in DLSAG using any d-LRS construction

Meaning MLSAG, CLSAG, Triptych can be used

Obviously the scaling will be different in size/time

But essentially you increase from a 2-LRS (signing key, amount key) to a 3-LRS (signing key, amount key, timelock key)

Does unlock time per transaction mean all outputs have the same unlock time?

You also need to change how range proofs are structured, in a nontrivial way

In theory, yes

But it would depend on how it's designed

Yep @sgp_ that's how it works currently

Anyway, there's a marginal increase in transaction size to include the necessary auxiliary commitment data

But more notably, there's a time cost that scales linearly with the ring size

Maybe market research some come first to see if there's a demand for per-output. Has this been done at all?

*should come

This time cost exists regardless of whether the locks are per-output or per-transaction

I have C++ timing data for CLSAG to show this, and could modify the new Triptych code similarly

(no point doing it for MLSAG)

Before there's too much time/effort invested in this, I think it'd be useful to determine what costs people think are acceptable to introduce this

The signature stuff is pretty straightforward (from 2-LRS to 3-LRS), but there's additional engineering work for a much different handling of range proofs, which would also need to change the fee structure due to Bulletproofs DoS scaling

Does this impact transactions that use the locks only or all of them?

and, of course, the timing hit needs to be considered

Well, for maximum uniformity all outputs would need locks

The lock could be set to 0

but the time cost is the same

Since for every ring member, you need to process its lock data

and the verifier can't tell which locks are 0 due to the commitment structure

I feel like knaccc since I can't imagine what utility timelocks have

Crossing borders

Would encrypting lock times prevent it from being used as a second layer building block ?

Constructions involving cross-chain and off-chain channels would need them

Isthmus: how many transactions use these locks again? I lean towards not pursuing this unless there's a known demand

moneromooo: encrypting timelocks were originally designed for 2nd layer stuff in DLSAG

i thought the second chain requires the kind of time locks that we don';t have yet

They aren't required for DLSAG, but they are useful to avoid spend heuristics

second layer, sorry

e.g. ring members whose locks have just expired may be more likely to be true signers, etc.

but i guess both types would need encryption

Anyway, if the decision is to support timelocks, requiring the commitment structure is good for mitigating heuristics, but it comes at a definite cost

and this cost scales with the ring size

I'd be ok with a fair cost if it is instrumental having a good second layer, but not really otherwise.

it seems pretty integral if we want monero to be programmatic money

To be clear, a solution like DLSAG requires timelocks, but does not require encrypted timelocks

It is highly beneficial for uniformity if the timelocks are encrypted, however

Isthmus it might help the proposal if there were some basic estimates of costs related to timelocks (storage requirements, additional EC ops), for both CLSAG and then for Triptych.

UkoeHB_: I already have this data for CLSAG, and presented it quite a while ago

For Triptych there are estimates (the C++ code didn't exist at the time)

ah, in which case a link would be nice

I can dig it up after the meeting

That's only the costs for the signature and commitments though, right sarang?

FWIW the branch is here for 3-CLSAG: github.com/SarangNoether/monero/tree/3-clsag

TheCharlatan: the range proof wouldn't necessarily incur any extra costs

Depending on if/how the limits are changed

If desired, I can update the new Triptych C++ code to support timelocks, for data on performance differences

it'd be pretty straightforward to do

I only really support the research if we know there's a solution on the table that Monero will use for second layer stuff. The "how to encrypt" question will be answered faster than the audit process. Maybe I'm not understanding the application, but I perceive this bug hurdle as needing to come first

Anyway, I support the idea if it's based on a solid understanding of the costs, and has general consensus

sgp_: we know exactly _how_ to do it

(in terms of signature handling)

I meant selecting which is best

What's not known are specifics related to range proofs, fee structure, etc.

fee would be pretty simple to update afaik

Perhaps. What changes is that the aggregated range proof now needs to account for newly-generated outputs, as well as a proof for each timelock input

But it's still something that would need to be considered and completed in the design/deployment process

right

and it also complicates things since there are currently no specific input limits

whereas Bulletproofs have a ceiling-power-of-2 verification cost, which is why we limit the output count

Having a separate bulletproof makes little sense from a size perspective

ah hm

per-input timelocks may be expensive, but I defer to the estimates /o\

Could we have 1 time per transaction, and an encrypted bit with each output

1 = use encrypted timelock

0 = default (10 blocks)

Isthmus: you still need the signature and range components

How you assign timelock commitments to outputs isn't really relevant there

Mmkay, was just trying to think of a way to bee able to lock 1+ outputs without locking your change (without having an encrypted timelock for each output)

That's a pretty minimal size cost

The real kicker is verification

and the specifics on range proof structure

Yep, those are key things to nail down first

Well, we have CLSAG code to give real numbers on that cost

and it's easy to modify Triptych to give its costs

What is not known is what time hit is considered reasonable

"as low as possible" isn't a design decision

Can I step in since I really need to make sure I understand the big picture here

sure

of course

In order to add a feature, there should be at least some stated use for it, especially if there are costs

nvm per-output timelocks would be cheap at 8 bytes per additional output, most cost is on input proving side

So the main benefit is the ability to add things like DLSAG and other related protocols that could allow second-layer right? That time locks are necessary for second-layer solutions we know about?

Well, and we allow timelocks right now; but they have multiple accepted specifications, and likely introduce spend heuristics

s/likely/do/

So their presence and optionality introduce fingerprinting

right but they aren't used as far as we know for anything in particular?

^^ good point

Not only are timelocks used

5 different formats are used

See the documentation linked above

that's what I meant

So SOMEBODY is using them

They're anonymous, unfortunately, so I don't know their use case

Requiring a uniform format is an obvious first step

what fraction of all tx have non-zero timelocks?

sgp_ they are also useful for atomic swap purposes, if you are looking for specific features.

was about to ask same UkoeHB_

TheCharlatan, but not in the state that they currently exist, right? I thought atomic swaps require the kind of time locks that bitcoin has - i.e., this tx can't be mined until certain time

yeah right now its payment channels (lightning network) and atomic swaps, for the most relevant application of timelocks (i think)

They're not super widely used, on the order of 10k nonzero locktimes

Of course, neither are subaddresses ;- )

total number of txs is 10M order of magnitude?

6M

Almos 7M

*almost

.c 1e4/7e6

dumb idea: why not threaten to remove this feature entirely unless someone justifies the need?

0.1% more than I would've guessed

since we are spitballing a bit, Istmus and I also discussed introducing a more compact format. So if encrypting them is deemed undesirable, I believe we should still change their current behaviour to something more sane and less dangerous.

if these are caused by someone fucking around for no purpose, then why bother having them

compact format?

Do you mean supporting only a single uniform format?

Because this seems like a natural first step

iirc they are varints atm, so at most 9 bytes

At least removing the fingerprinting possible within the use of timelocks

in order for the *cool* time-lock applications to come around, we need to agree to implement something else which would come with a large advance notice. This hasn't happened obviously

Well, and there is no DLSAG-type payment channel use currently available

@UkoeHB_ I thought it was uint64. I got a few outputs locked until 18446744073709551614 (about 500 billion years) over the weekend :- P

Isthmus: something something store of value

Using a single format for timelocks seems a sensible first step to me

varints have up to 63 bits of information from what I understand

oh yea

OK, so in the interest of time, what's a good next step in this design process?

cost estimates

Isthmus TheCharlatan: let's discuss that after the meeting

Exactly, but a varint for a timelock is completely overblown. There have been a lot of discussions on this in Bitcoin as well, for example to restrict the size to a 1 byte value that is then interpreted as a power of time.

single format

I say the cost estimate of only the cheapest option to begin with to see if that action is warranted

Personally I would get rid of time based lock times entirely.

That introduces a correction term when blocktime changes

But that's easy enough to do

TheCharlatan: haha exactly, or at least aggressively ask for justification from people who use them

OK, so beyond investigating optimal single-format cleartext use and updated cost estimates, anything else on this topic for right now?

(otherwise we could discuss it for hours...)

going once

going twice

sold

nope, I just want to stress that we need to know why they are used before slowing down transactions

I can briefly share a couple things in the time we have left

I overhauled Triptych verification to support common-key batching

and s/time/two - deleted the wrong word :(

New timing data: usercontent.irccloud-cdn.com/file/TWAkCeJJ/timing.png

This data represents the input-amortized verification cost for a 2-input set of signatures

Assuming the same ring is used across both inputs for Triptych

(for MLSAG/CLSAG it doesn't matter)

I also overhauled the MLSAG tests for better consistency with the other series

wait isnt that way faster?

It should be

What are amortized inputs?

If you have a 2-input transaction, you need to compute 2 signatures

For MLSAG/CLSAG, this takes twice the time as one signature

For Triptych, if you use the same ring, you get huge batching benefits

So this is the per-input cost for a 2-input transaction

For higher-input-count txs that would share rings, the benefits get even better

🥳

The gray crossed lines are centered at the current N=11 MLSAG point

This implies that Triptych becomes slower than right now (for 2-input txs) between N=64 and N=128

(but you can't split the difference... you need to pick a power of 2)

Anyway, hopefully this gives more realistic timing data, at least across 2-input txs

is 128 about the same time as DLSAG 12? 13?

You can use my `triptych` branch and `clsag-device` branch to construct this data for yourself

I don't have C++ data for DLSAG

soory I meant MLSAG

I'd have to run some quick MLSAG tests on those intermediate numbers

I can have that shortly after the meeting (need to do a new build)

it's fine, not that important

It's easy, just takes a few minutes

Anyway, that's what I wanted to share

cool stuff

Does anyone else have research to share (we're running a little long, but that's ok)

very cool

hi yes, this proposal went up this week monero-project/monero #6456

it's a synthesis of discussion and research from IRC over the past months

It's very comprehensive :)

I admit that I haven't had a chance to sit down and devote time to it :/

However, do you have any concrete suggestions at this point UkoeHB_?

there needs some debate about whether to pursue Janus, and which solution to adopt, but otherwise tx structure recommendations, sorted tlv, and view tag all seem concrete to me

Neat

I'll devote time to it before the next meeting for sure

also moving to mandating 1 tx pub key for 2-out tx, and 1 key per output for >2 out tx

Many thanks for continuing work on that

OK, let's briefly review ACTION ITEMS before we adjourn

"1 tx pub key for 2-out tx" < is that assuming that every 2-output txn has a change output?

*change or dummy

we only have to make that assumption if Janus is implemented

Ok, so then if there's a txn being split between 2 (non-change) recipients, it must be constructed as a 3-output txn with a dummy output, right?

right

Eh that seems harmless. Is a corner case anyways.

Sorry @sarang go ahead

Someone volunteered to do a review of the CLSAG code, which was very helpful... they also recommended adding Poly1305 authentication to wallet encryption, which is a good idea to prevent chosen-ciphertext adversaries

Aside from that, I'll pull up some 3-CLSAG and 3-Triptych data to help the timelock discussion, as well as some stuff on Arcturus

that's all for me :)

Anyone else?

I'll expand the timelock proposal with some more references/data/use cases

And I'll probably finish another quantum-resistance proposal today or tomorrow, currently incorporating feedback into the first draft

great

Any other final action items before we adjourn?

Oh yea, and I'll read UkoeHB_ 's epic github issue :- )

Righto, we are now adjourned! Thanks to everyone for a great meeting

Logs posted shortly; discussion can of course continue

sgp_: 2-input amortized Triptych corresponds to 13-MLSAG

thanks

also Isthmus and TheCharlatan: what would be most helpful from me regarding 3-CLSAG and 3-Triptych timing data?

I don't want you to do unnecessary coding work that's already been completed

Definitely want to take advantage of your extant work. :- )

Yeah, I won't re-implement anything you have already built ^^

no prob

The 3-CLSAG repo would need to be updated to reflect some new verification optimizations

the 3-Triptych stuff is straightforward but not complete yet

For initial timing purposes, ignoring range proofs is probably quite reasonable, since those scale much better (if they need to scale at all)

sgp_: Has any progress been made on the 'official' audit of CLSAG?

<[keybase] seddd>: apologies for missing the meeting (network issues)

No prob

Agenda issue has logs

Anything you'd like to share now?

<[keybase] unseddd>: ah, better :) (consistencyinnames)

<[keybase] unseddd>: this week I'll be fuzzing

<[keybase] unseddd>: have a fuzz test written, and will do a PR (against clsag-device?) when all the kinks are worked out

<[keybase] unseddd>: will also be reviewing monero/6456, brainstorming, etc

Neat! Yes, please make any PRs against the `clsag-device` branch of `SarangNoether/monero` repo

(for CLSAG)

<[keybase] unseddd>: will do :)

Test code for 3-Triptych, relevant to earlier timelock discussion: github.com/SarangNoether/monero/tree/3-triptych

And corresponding timing data: usercontent.irccloud-cdn.com/file/usvO8BF4/timing.png

Note that _only_ the yellow series represents timelock-compatible signatures

All other data is identical to that shown earlier today in the meeting