It seems some care was taken to memwipe variables that store private keys as soon as they are done being used (see e.g. construct_tx_with_tx_key()). However, \alpha variables for MLSAG signatures are not memwiped, and they can be trivially used to recover the private key from any completed signature. Should this be updated?

Yes.

(either make a patch or point to the variables needing wiping)

Last used here: github.com/monero-project/monero/bl…/master/src/ringct/rctSigs.cpp#L257

This alpha: github.com/monero-project/monero/bl…/master/src/ringct/rctSigs.cpp#L192

Probably should be wiped, true

that seems the spot, and even the multisig kLRki \alpha term is copied into that same variable, so it only gets at most two instances within the signing process. I should probably look to make sure kLRki is only passed by reference everywhere else (and that the initial generation of \alpha for multisig is safely handled)

this function also copies it github.com/monero-project/monero/bl…/src/device/device_ledger.cpp#L1996

Will you make a patch or should I ?

Can you do it? Im not sure exactly what to do

looking at this function get_multisig_kLRki(), is it safe? github.com/monero-project/monero/bl…37938/src/wallet/wallet2.cpp#L12802

seems to make a new definition of kLRki

wallet2::export_multisig() also

k is secret, L, R, ki aren't, right ?

correct

Thanks. I'll patch that tomorrow probably.

ok lmk and Ill review

wallet2::get_multisig_composite_kLRki() also has a copy

transfer_selected() and transfer_selected_rct() has several copies in the src, sources_copy, and sources_copy_copy variables

construct_tx_with_tx_key() has a new kLRki

Are you assuming leakage of only alpha, and no other non-sig data?

alpha seems the most important one, although I guess you could wipe everything else

I mean in the situation you are considering

Im wondering about the safety of pointer variables as well, although my ability to read c++ pointers is still weak

As I said before "care was taken to memwipe variables that store private keys as soon as they are done being used". Whatever situation that was implemented to counter, is a situation that could also exist for \alpha variables.

Idk what that situation is

This is the original PR monero-project/monero #4268

everything using kLRki in rctSigs.cpp appears to pass by reference

maybe stoffu can comment

Are you concerned about `alpha` alone, or in conjunction with other signature input data

alpha alone, since with alpha and the signature output you can compute the signing one-time address's private key

k = (alpha - r)/c

A straightforward fix

Meeting today is at 17:00 UTC

.time

UkoeHB_: monero-project/monero #6441

moneromooo: see github.com/monero-project/monero/bl…/master/src/ringct/rctSigs.cpp#L551

Any reason this shouldn't be `memwipe(sk.data(), sk.size() * sizeof(key))` instead?

I dunno. Are they all secret ?

`sk[1]` is a commitment-dependent signing key

No reason it should stick around, really

That sounds like a yes. I'll change it.

CLSAG_Gen should get the same scope-dependent wipe on the key `a`

OK

I updated my `clsag-device` branch for it

Is there a point in me merging anything else for CLSAG now ?

Well, the ledger PR remains not fully tested (according to cslashm) until it gets on testnet

and the device-specific functions have been already moved out to device_default as well

So I'm not sure how you want to proceed, since the trezor functionality is not completed AFAIK

OK, time for the weekly research meeting

Let's get started

GREETINGS

hi

hi

hi

ahoy

On to ROUNDTABLE, I suppose

I've been working on papers for PoPETs submission, which has been a blast

hello!

As well as some review for a paper on hierarchical one-of-many proofs

Finally, plenty of code relating to Triptych

Not too much exciting stuff to report overall

Any particular questions?

hierarchical one-of-many-proofs sounds interesting. can you link the paper?

It's not on the IACR yet (and I am not the author)

Otherwise, anyone else who wishes to share research topics is welcome to do so

what are hierarchical one-of-many-proofs?

An extension of the Groth proofs used in Triptych and Lelantus that trade size for prover complexity

They use a clever layering technique

smaller size for increased prover complexity?

Other way around :)

ok :)

The author thought there could be verification savings in certain cases, but I don't think that's the case if you do batching in the usual way

Does anyone else have research topics they'd like to share or discuss here?

I can give an update on the scaling and fees issue #70

Sure!

I have a solution for the scaling side and minimum relay fee. I am still finalizing the fee ratios

Basically we can use the long term medium to deal with this

Can you summarize?

Sure

1) Put a cap on the rate of fall of the long term medium so that it falls at the same rate it rises

2) Make the penalty free zone dynamic as the greater of 300000 bytes and 25% of the log term medium

Will that 300K value change with CLSAG?

No the reference transaction size will to 2100

yes

But there are no plans to change the fixed-value penalty-free size?

The minimum relay fee will very close to the old normal fee

So for the current minimum penalty one the minimum fee will actually go up ~2.5x

ArticMine what issue/risk is this solution tackling?

A sudden drop in use followed by a recovery

In many ways similar to COVID-19

What would be the shortcomings of the current implementation in that situation?

This create the scenario

Ah, couldn't find issue. Thank you

The basic problem is a sharp rise in fee that can take months or year to come back to normal

Also a very sudden drop in the long term medium that also could take months or years to recover

Issue #70 does not mention COVID-19 but COVID-19 is a very good scenario

Will you have specific code or pseudocode soon to allow for simulations prior to any recommended deployment?

Also there are scenarios where COVID-19 cold lead to a significant demand on the Monero network in terms of transactions

Yes

I have all the formulas now except for the fee ratios

OK, thanks

Still working on that

I assume you'll post them to the issue you linked?

Yes that is where I will post this

Got it

Anything else of note that folks wish to discuss?

I know UkoeHB_ recently posted his new version of Zero to Monero

not sure if he's around right now

Yes that is excellent

but that's on the getmonero library page, along with a link to the TeX source repo

and there was also a suggestion from UkoeHB_ for updating how MLSAG secret data is wiped, which was a great catch (PR now available)

Anyone else?

Otherwise, we can move on to ACTION ITEMS for the week

I will be continuing work on a C++ implementation of Triptych for timing efficiency tests

as well as some new material for the multi-signer Triptych variant's security model, prior to the PoPETs submission deadline

Oops, just got back. Nice work Artic!

Isthmus: do you have any research or topics you'd like the group to discuss?

Ah, I've been neck deep in Zcash all week.

We did find that funny transaction over in NRL

Probably more of a novelty than anything else

Lemme grab the link

Anything relating to the Zcash lock times that's been observed in the Monero network too?

Or any lessons to learn from the Zcash work?

Monero's lock times look very similar

Actually there's also 4 bands

Like this:

0

{1,3,8,10,12}

{block heights ~ 1xxxxxx}

and then UTC timestamps

It's all over the place, and I don't think any of it is enforced, so the lock_time field is really just an arbitrary memo xD

In Zcash too?

Did you analyze the distribution of the UTC timestamps as well?

Lemme try to find that notebook

Shoot, I don't have it on this computer

No worries

Any other action items for the week?

So what's up with duplicate subaddresses?

Isthmus: were those the only two such examples?

You suggested "novelty", heh

No, there were several, But all very similar, that one is representative

hmm

Along those lines, it was suggested (last week, IIRC) to move some of the more standardized tx fields out of extra

Which wouldn't eliminate strange behavior, of course

but could help with distinguishing factors like ordering etc.

Any further thoughts on that?

I'm working on it a bit, but need to move ideas from my head into diagrams. Will share here in a week or two.

Might have a new approach, but tbd

New approach to what exactly?

Transaction structure?

Nah, mental models that more accurately describe information leaks

But it doesn't all fit together yet.

My action item is making it into something comprehensible by next week xD

ah ok

Neat!

We're coming up on the end of the hour

Any last questions, topics, action items, etc.?

Just curious what's your perception of relevant research over the next 6 months. Everything staled? Business almost as usual?

Conferences and events are mostly canceled or moved to remote?

Oh you mean in the broader research community?

Seems that some conferences planned for later in the year are playing it by ear for now

Yeah, anything relevant to MRL and Monero, how do you see things going?

The cancellation of the Konferenco was unfortunate, but necessary

Otherwise, calls for papers seem to be mostly continuing as normal, which is great to see

ok good to know thank you

Perhaps bored academics stuck at home will be more eager to read and review new research too

and go straight for journals :)

Oh interesting question @binaryFate

That reminds me, when do we want to research quantum-resistant PoW and/or quantum-resistant cryptography?

Note that pqPoW isn't super important in the short term

"before it's too late"

However it is unfortunate that the Monero transaction I make tomorrow will most likely be decrypted by a quantum computer during my life time.

I know that suraeNoether had taken a particular interest recently in post-quantum signature constructions, but I don't know of any relevant efficient results at this point

It might be nice to have somebody put together a survey of (1) Exactly which pieces of Monero will be broken by quantum computers (2) Potentially Monero-compatible solutions

The reliance on discrete log hardness is the kicker

Yep, it's gonna be tricky.

But, I believe we can do it! If not, Monero has a very limited shelf-life :- P

I feel like the bipartite graph matching project that suraeNoether is verifying will be one of the most vulnerable

Graph matching is already parallelizable without a quantum computer

It's just a very large search space in general

On that happy note, let's go ahead and adjourn!

Thanks to everyone for participating

Logs will be posted shortly to the agenda GitHub issue

Thanks sarang and everyone!

Thanks

Can you imagine how cool it will be if/when Monero is the first privacy coin to implement quantum resistant mechanisms? Checkmate. It'd be *absurd* for anybody to use alternatives that they know will be retroactively anonymized, when there's a functional open source alternative.

Especially if we can get rid of decoy-based sender anonymity in the process.

I've tangentially followed some Zcash github discussions on the topic, since there are certain similarities

e.g. key images vs. nullifiers

Isthmus, are zcash current and near-future implementations not very quantum resistant?

IIRC at least in Sprout, a quantum adversary can test a supposed output destination

and can use nullifiers to detect when an output is spent

I'm not sure what, if anything, changes in Sapling

@sarang is it important that atomic swaps between btc and xmr do not have a timelock?

Has the idea of giving miners scrip for unused block size been considered? Orthogonal to the soft limit - this incentivizes the creation of smaller blocks

(below the limit)

what exactly do you mean by scrip?

Tokens that can be redeemed to temporarily up the block size limit.

So, if the current limit is 1MB, your blocks would have the size of at least all transactions with fees > 0, and then all transactions with fees > penalty.

So in practice it seems like miners would fill the blocks up to the limit with transactions which are just profitable enough, and then require large rents for whenever the demand surges.

So, extremely cheap during off-peak hours, extremely expensive during peak hours, since you need to 'push through' the soft limit

If you'd instead say, "the limit is 1 MB, if you only use 300 KB you get 700 K 'byte tokens'," then you'd get a more efficient use.

That way, the low-rent transactions wouldn't get mined, since the miner would rather just take the block size token things and use them for future blocks during peak hours.

In effect, the fees wouldn't depend on the instantaneous load (tangent), but on something like the expected future load (secant).

I don't think that idea has been discussed, afaik, but it seems like the implementation may be quite complex and could result in some unanticipated consequences

ArticMine has certainly given a lot of thought to block rewards and fees so maybe he has some thoughts

I don't know if Monero supports colored coins well. There would be some market-based complexities, in which smaller miners might find it annoying to sell off their scrip

Whereas pools can just dump them in the open market.

Then again, it _seems_ like it should be possible to do on-chain atomic swaps for them. So, you have 10 scrip, and you want to sell them for 1 monero, you create a transaction which ... does this, atomically, and send it.

yea that's another issue - monero does not currently have any colored coin implementation, and there are possibly some privacy implications with them, though if they were only used in coinbase txs that would probably not matter

there's no scripting capability in monero txs

Can't you create a transaction that spends multiple outputs though?

yes

Like, if I want to create a (completely unneeded) CoinJoin transaction, can't I do this?

so if A has 1 XMR and B has 10 XMR, it's possible to create a transaction with moves 9 XMR from B to A, but also one which moves 11 XMR into a box, and then atomically 10+1 out of it. Right?

Are you aware of Monero's dynamic block weight? Having a hard time following your argument

I guess, each input will have its own ring signature though, so not sure if that would impact your scheme

UkoeHB_: Yes. See the first messages.

<[keybase] seddd>: sarang: will there be a security proof for dual-target dlog in future Arcturus revisions?

The block weight takes away some of the incentives, since it's still usable, but this would make things more efficient.

jwinterm: For the colored coins?

I am not sure how you'd do colored coins in Monero. A very, very, very ugly hack might be to just not make them private.

Say something like, "these are not a currency, you shouldn't use these for transactions, and they expire 1 year after creation"

seddd: it'd be nice to reduce that problem to a known hardness assumption

but I don't have that yet

and then just have them move around without any privacy. The transactions would however reveal who's a big miner and such.

So I hope there's a better way.

the only potential implementation I know would be to put some data in tx-extra field, which has been discussed as a privacy issue

But aside from those logistics; are there any other problems with the idea? You mentioned unanticipated consequences

which unanticipated consequences is it you anticipate? ;)

donaldrumsfeld.mp4

<[keybase] seddd>: sarang: no worries, am looking at the traditional dlog proofs and fiat-shamir proofs. Down to work on the security proof for dt-dlog with you

There are a lot of design choices that went into Monero's current dynamic block and fee system, and there is even ongoing research to improve it. Idk if it's reasonable for anyone to comprehend a whole new system and all its facets very quickly.

If you can find a reduction from the dual-target game, that'd be great

<[keybase] seddd>: Even if that ends up just being a reduction to classic dlog

It would help if you could draft a clearly explained proposal, contrasting it with current design choices.

<[keybase] seddd>: Am very far from suggesting design changes, still trying to figure out exactly what's going on 😅

Not you seddd, talking to yanmaani

<[keybase] seddd>: Will definitely provide a write-up w suggestions when/if I have them

UkoeHB_: Right, makes sense.

Any pointers where I should post it?

Should I just like write it and post on pastebin and link here?

<[keybase] seddd>: Lol for sure UkoeHB_

yanmaani: a good place might be the monero-research-lab github issues

thanks UkoeHB_

For explanations of current and ongoing design: zero to monero v2 section 7.3, and this repo issue monero-project/research-lab #70

Ah, so the mental model I had was a bit off- there's always a penalty, right?

"minimum fee"

or does the miner get this?

or no, that's just relay policy and thus useless

or/

OK, so rough draft here if anyone wants to read: pastebin.com/R7Eae6rE

oops, typo on line 18. "324 units" -> "324,000 units"

yanmaani: hm I wonder about this idea that profit-maximizing miners will artificially maintain large block weights. see ztm2 ch7 footnote 35 (pg 68). A miner only moves into the penalty free zone when the marginal fee from adding a tx is higher than the marginal penalty. This means ALL tx in a block must have that marginal fee, otherwise the miner will reject it in favor of the marginal penalty. However, if

block sizes are high then tx authors will just use much lower fees than the marginal penalty of even the reference tx (the tx to go from full penalty free zone to full +1) (currently min fee is .2x the reference tx fee). Rather, a miner wants blocks as small as possible so tx authors are collectively forced into buying penalty zone space.