00:38:00 <kayabaNerve> 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)
04:19:47 <Isthmus> Nice to meet you kayabaNerve - looking forward to chatting more! What kind of research are you interested in?
04:19:47 <Isthmus> 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.
04:19:47 <Isthmus> I assume there is a good reason for this,  I just haven't spotted them yet
04:22:00 <kayabaNerve> 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.
04:22:42 <Isthmus> s/signing/MLSAG
04:22:43 <monerobux> Isthmus meant to say: Unrelated, why do we pick random MLSAG 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.
04:24:05 <Isthmus> Glad to have you join us!
04:24:58 <kayabaNerve> 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
04:27:02 <kayabaNerve> Anyways. Have a link to your work/any CCS proposals? I'd love to read up
04:55:08 <sarang> Isthmus: signing scalars are all random except for the true index
04:55:37 <sarang> You can set the random ones to secret hash outputs
05:22:10 <vtnerd> I think what Isthmus was asking -> usually the issue is that the scalar cannot be re-used or it leaks secret index
05:23:04 <vtnerd> for instance, eddsa uses hash output to get deterministic signatures, but this shouldn't yield two identical scalars unless the hash is broken
05:25:01 <vtnerd> but Im not sure off-hand how easy that is for monero
05:25:51 <vtnerd> or possible. you probably can't remove any additional values beyond what clsag has removed though
16:14:30 <sarang> 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
16:14:49 <sarang> This was looked into earlier, and I even have some example code showing how it works
16:35:59 <Isthmus> "using hash function output for MLSAG/CLSAG scalars is possible" < this is more along the lines of what I was thinking
16:35:59 <Isthmus> 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
16:35:59 <Isthmus> Might not make sense for the signing scalars since only N-1 are randomly selected
16:35:59 <Isthmus>  
16:36:35 <Isthmus> "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
16:46:46 <sarang> Isthmus: using hash functions does not change the number of elements in the transaction
16:47:06 <sarang> It merely (a) reduces the reliance on a non-hash RNG; and (b) allows for private recovery of the signing index if desired
16:47:29 <sarang> Note that it is absolutely not possible for the network to verify if this has been done (and it must not be possible)
16:47:46 <Isthmus> ^ yeah that’s what I meant
16:59:58 <sarang> But yes, it's been discussed before that random quantities could be used via hash functions
17:00:04 <sarang> even e.g. for range proofs etc.
17:00:12 <sarang> Then you do have to consider reuse etc.
20:16:46 <Isthmus> Are all S of the signing scalars randomly selected? Or 1 is specified and the others (S-1) are selected from PRNG?
20:17:03 * Isthmus dusts off ZtM
20:18:21 <Isthmus> s/signing scalars/signer-selected MLSAG scalars/
20:18:21 <monerobux> Isthmus meant to say: Are all S of the signer-selected MLSAG scalars randomly selected? Or 1 is specified and the others (S-1) are selected from PRNG?
20:19:54 <Isthmus> Sorry if these are silly questions, just noodling around for the weekend
20:29:04 <Isthmus> Wait now I’ve just confused myself
20:30:52 <sarang> All but one are (P)RNG
20:31:07 <SerHack> It Hurt Itself in Its Confusion!
20:31:21 <sarang> The index of the non-(P)RNG is unknown publicly
20:31:39 <sarang> but is still uniformly distributed
20:31:40 <Isthmus> lol @serhac
20:32:20 <Isthmus> And the # scalars = # ring members, right?
20:32:24 <sarang> Yes
20:32:30 <sarang> in CLSAG
20:32:40 <sarang> in MLSAG there are twice as many (signing keys and commitment keys)
20:48:42 * Isthmus continues with CLSAG for simplicity
20:48:42 * Isthmus Okay, so we need N scalars. So we have `s*` (the real one), and then we hit the (P)RNG `N-1` times for the rest of the scalars. And then store all of them on the blockchain forever
20:48:42 * Isthmus What if, instead, we start with `s*` and hit the RNG once for a secret integer `m` on [0,N)
20:48:42 * Isthmus Then calculate `q=s*-m`
20:48:42 * Isthmus Instead of publish N scalars in the transaction, you simply publish the single value for `q` :- )
20:48:42 * Isthmus Then when transactions are being parsed, the scalars are  calculated`(q, q+1, q+2, ... q+N-1)`
20:48:59 <Isthmus> Wat... IRC cloud bug, those were not supposed to all be /me
20:53:59 <sarang> Isthmus: how does the verifier know which indices in verification should correspond with which scalars?
20:54:12 <sarang> The verifier needs to perform a hash computation with each scalar in order
20:54:35 <sarang> There's essentially a matching between public keys in the ring and scalars in the signature
20:55:05 <sarang> 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
20:55:12 <sarang> *keys
20:55:19 <sarang> (there's a signing key and a commitment key)
20:55:46 <sarang> This is a big reason why the next-gen sublinear constructions are so much better
20:55:59 <sarang> They don't rely on this Schnorr-style "which scalar is it" approach
21:07:20 <Isthmus> RE indices, hmm, a few ideas
21:07:20 <Isthmus> 1) calculate `m` first, and arrange the keys so that the true one is the mth element in the list
21:07:20 <Isthmus> or
21:07:20 <Isthmus> 2) Include mapping in tx, (q, [map1,map2,map3,map6])
21:07:20 <Isthmus> for example
21:07:21 <Isthmus> (325a7853132911d5de5c6a6085d7e5ee720dcbd5003dbf304a35717924723206, [8,9,7,4,3,10,0,2,1,5,6])
21:08:06 <Isthmus> so s* was 325a7853132911d5de5c6a6085d7e5ee720dcbd5003dbf304a35717924723208
21:08:11 <Isthmus> and m was 2
21:09:37 <Isthmus> Oh shoot, gotta go.
21:24:45 <sarang> You have to specify all the (P)RNG scalars in advance, before knowing the non-(P)RNG scalar
21:24:49 <sarang> Which seems to break this idea
21:25:07 <sarang> i.e. you can't retroactively choose them
21:33:57 <Isthmus> Oh duh
21:34:07 * Isthmus facepalms
21:45:55 <sarang> test
21:45:55 <monerobux> Test failed
21:46:25 <sarang> Isthmus: nah, that's my bad... I don't think I explained the construction of the scalars very well
21:58:17 <Isthmus> test
21:58:17 <monerobux> Test failed
21:58:35 <Isthmus> test&success=1
21:58:35 <monerobux> Test failed
22:02:09 <Isthmus> https://usercontent.irccloud-cdn.com/file/ccn6xrGb/image.png
22:02:11 <Isthmus> https://usercontent.irccloud-cdn.com/file/vbvRUHV6/image.png
22:02:38 <Isthmus> So the ss is [(resp1, key1), (resp2, key2)]
22:02:55 <Isthmus> and then the `cc` in the txn is `c1` in the ZtM clip, right/
22:07:25 <sarang> IIRC the `ss` array is the two-dimensional vector of scalars
22:07:43 <sarang> (I hate the MLSAG code notation and structure for its unnecessarily complexity...)
22:08:16 <sarang> In theory you can generalize out MLSAG to any dimension, but we don't do this...
22:08:37 <sarang> so the CLSAG code nixes this entirely and is written specifically for two-dimensional keys
22:08:40 <sarang> (signing and commitment)
22:14:55 <Isthmus> Ahhhh
22:15:03 * Isthmus has been on a notation hunt all afternoon
22:15:15 <Isthmus> And just hit a dead end -_-
22:15:16 <Isthmus> https://usercontent.irccloud-cdn.com/file/CeLMJMxu/image.png
22:15:31 <Isthmus> Do you know which paper that notation comes from?
22:15:40 <Isthmus> I'm trying to sort the variables into the 4 buckets
22:16:34 <sarang> It's from the BP preprint
22:16:48 <sarang> https://eprint.iacr.org/2017/1066
22:17:00 <sarang> I tried to follow the preprint notation as much as possible
22:18:33 <Isthmus> Ooh perfect
22:21:07 <Isthmus> Woah that's a heck of a paper
22:21:09 * Isthmus rubs eyes
22:21:52 <sarang> aye
22:22:07 <Isthmus> So essentially all of the bp outputs are bucket 4 [output of cryptographic function, expected to be uniform]
22:22:32 <Isthmus> Right? Or are any of them user-selected values?
22:23:00 <sarang> None are directly user-selectable
22:27:08 <Isthmus> https://usercontent.irccloud-cdn.com/file/iNR0fmQY/image.png
22:27:40 <Isthmus> Okay, I think the table is complete then. Are the `ss` values the only other user-selected variable that's expected to be uniform?
22:28:05 <Isthmus> (bucket #3)
22:29:37 <sarang> What does "expected" mean in this specific definition?
22:30:27 <sarang> But at first glance, yes
22:40:36 <Isthmus> 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.
22:40:36 <Isthmus> (a hypothetical exception would be, for example, some wallet in the wild selects those scalars only from 1 to 1000)
22:40:36 <Isthmus> For something in bucket #4 like output keys it means that we expect uniform output from crypto functions
22:40:36 <Isthmus> (a hypothetical exception would be, for example, if some wallet is re-rolling transaction private keys to generate vanity stealth addresses ending in 'xmr')
22:42:31 <Isthmus> 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"
22:43:13 <UkoeHB_> the extra field is mostly uniform, since it usually just contains the 32 byte tx pub key (a curve point)
22:44:44 <Isthmus> That's where the on-by-default encrypted PIDs live too, right?
22:46:21 <UkoeHB_> yes, although there is only a default ePID for 2-out tx (a dummy most of the time)
22:48:16 <Isthmus> Gotcha. So the tx_extra field, as a whole, should fail the diehard tests because tags and whanot are not expected to be uniform
22:48:17 <Isthmus> But if we parse it out into subfields, then we *would* expect some of those to pass (for example tx_pub_key and ePID)
22:49:58 <sarang> Right