Isthmus: Would love to hear about said research. Long time fan of Monero, but only a recent participant in the community (though I have kept up to date on hard forks and worked with the codebase before)

Nice to meet you kayabaNerve - looking forward to chatting more! What kind of research are you interested in?

Unrelated, why do we pick random signing scalars? Why not just hardcode that they're always equal to 5, and then you don't even have to include them in the transaction.

I assume there is a good reason for this, I just haven't spotted them yet

Isthmus: I'm not a cryptography designer or developer. I implement some higher level tech and piece together others. I just like to stay up to date, so hearing you're actively working in the field piqued my interest.

s/signing/MLSAG

Glad to have you join us!

I've been a fan of Monero in a while and worked in cryptocurrency for longer :) Only just recently started chilling here. I did some Monero code a few weeks before the last hard fork though, so I can't explain MLSAG, but I do know the overall CN structure/theory

Anyways. Have a link to your work/any CCS proposals? I'd love to read up

Isthmus: signing scalars are all random except for the true index

You can set the random ones to secret hash outputs

I think what Isthmus was asking -> usually the issue is that the scalar cannot be re-used or it leaks secret index

for instance, eddsa uses hash output to get deterministic signatures, but this shouldn't yield two identical scalars unless the hash is broken

but Im not sure off-hand how easy that is for monero

or possible. you probably can't remove any additional values beyond what clsag has removed though

vtnerd: using hash function output for MLSAG/CLSAG scalars is possible, and in fact can be useful if you later want to be able to (non-publicly) recover the signing index

This was looked into earlier, and I even have some example code showing how it works

"using hash function output for MLSAG/CLSAG scalars is possible" < this is more along the lines of what I was thinking

That in general, any number that is selected by the user and then published on the blockchain could be (depending on its nature) set to a hardcoded value or a hash function output. Provides both smaller transaction sizes and less room for implementations to pick the values "randomly" (narrator: not randomly) in some way that sticks out

Might not make sense for the signing scalars since only N-1 are randomly selected

 

"scalar cannot be re-used or it leaks secret index" < does that mean re-used within the same transaction? Will leak the index of true ring member

Isthmus: using hash functions does not change the number of elements in the transaction

It merely (a) reduces the reliance on a non-hash RNG; and (b) allows for private recovery of the signing index if desired

Note that it is absolutely not possible for the network to verify if this has been done (and it must not be possible)

^ yeah that’s what I meant

But yes, it's been discussed before that random quantities could be used via hash functions

even e.g. for range proofs etc.

Then you do have to consider reuse etc.

Are all S of the signing scalars randomly selected? Or 1 is specified and the others (S-1) are selected from PRNG?

s/signing scalars/signer-selected MLSAG scalars/

Sorry if these are silly questions, just noodling around for the weekend

Wait now I’ve just confused myself

All but one are (P)RNG

It Hurt Itself in Its Confusion!

The index of the non-(P)RNG is unknown publicly

but is still uniformly distributed

lol @serhac

And the # scalars = # ring members, right?

Yes

in CLSAG

in MLSAG there are twice as many (signing keys and commitment keys)

Wat... IRC cloud bug, those were not supposed to all be /me

Isthmus: how does the verifier know which indices in verification should correspond with which scalars?

The verifier needs to perform a hash computation with each scalar in order

There's essentially a matching between public keys in the ring and scalars in the signature

and the trick is to hide which scalar (all of which are uniformly distributed, but only one of which is not directly from a (P)RNG) corresponds to the signing key

*keys

(there's a signing key and a commitment key)

This is a big reason why the next-gen sublinear constructions are so much better

They don't rely on this Schnorr-style "which scalar is it" approach

RE indices, hmm, a few ideas

1) calculate `m` first, and arrange the keys so that the true one is the mth element in the list

or

2) Include mapping in tx, (q, [map1,map2,map3,map6])

for example

(325a7853132911d5de5c6a6085d7e5ee720dcbd5003dbf304a35717924723206, [8,9,7,4,3,10,0,2,1,5,6])

so s* was 325a7853132911d5de5c6a6085d7e5ee720dcbd5003dbf304a35717924723208

and m was 2

Oh shoot, gotta go.

You have to specify all the (P)RNG scalars in advance, before knowing the non-(P)RNG scalar

Which seems to break this idea

i.e. you can't retroactively choose them

Oh duh

test

Isthmus: nah, that's my bad... I don't think I explained the construction of the scalars very well

test

test&success=1

So the ss is [(resp1, key1), (resp2, key2)]

and then the `cc` in the txn is `c1` in the ZtM clip, right/

IIRC the `ss` array is the two-dimensional vector of scalars

(I hate the MLSAG code notation and structure for its unnecessarily complexity...)

In theory you can generalize out MLSAG to any dimension, but we don't do this...

so the CLSAG code nixes this entirely and is written specifically for two-dimensional keys

(signing and commitment)

Ahhhh

And just hit a dead end -_-

Do you know which paper that notation comes from?

I'm trying to sort the variables into the 4 buckets

It's from the BP preprint

I tried to follow the preprint notation as much as possible

Ooh perfect

Woah that's a heck of a paper

aye

So essentially all of the bp outputs are bucket 4 [output of cryptographic function, expected to be uniform]

Right? Or are any of them user-selected values?

None are directly user-selectable

Okay, I think the table is complete then. Are the `ss` values the only other user-selected variable that's expected to be uniform?

(bucket #3)

What does "expected" mean in this specific definition?

But at first glance, yes

For something in bucket #3 like the scalars, it means that we'd expect that all wallet developers have used a goodish PRNG over the correct range.

(a hypothetical exception would be, for example, some wallet in the wild selects those scalars only from 1 to 1000)

For something in bucket #4 like output keys it means that we expect uniform output from crypto functions

(a hypothetical exception would be, for example, if some wallet is re-rolling transaction private keys to generate vanity stealth addresses ending in 'xmr')

Oh, and in both cases, expectation of uniformity refers to something like "If we look at a million key images, they should be uniformly distributed"

the extra field is mostly uniform, since it usually just contains the 32 byte tx pub key (a curve point)

That's where the on-by-default encrypted PIDs live too, right?

yes, although there is only a default ePID for 2-out tx (a dummy most of the time)

Gotcha. So the tx_extra field, as a whole, should fail the diehard tests because tags and whanot are not expected to be uniform

But if we parse it out into subfields, then we *would* expect some of those to pass (for example tx_pub_key and ePID)

Right