03:59:13 <sarang> Wow, the authors of that ring signature paper from a few days ago have already updated the paper after I emailed them
03:59:24 <sarang> Kudos to them for such a quick response
04:00:08 <sarang> They kept the timing data but noted the flaw, and produced a safe variation but did not include timing data for it
04:00:28 <sarang> It would be interesting to see the comparison to CLSAG
04:01:27 <sarang> Same link as before: https://eprint.iacr.org/2020/333
04:02:41 <Slidy_> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech
04:02:41 <Slidy_> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech
04:02:41 <Slidy_> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech
04:03:17 <sarang> No thanks
16:49:43 <sarang> OK, was looking over IACR 2020/333 update, which proposes a modification to their original linkable ring signature construction...
16:50:03 <sarang> In appendix C, they present a Monero-compatible version of the signature that removes the use of a fixed-base key image
16:50:34 <sarang> However, the construction basically says "use an AOS ring signature with these public keys, this private key, and this list of generators"
16:52:06 <sarang> Hmm, nvm... I was using the AOS' signature, which doesn't work with a variable generator
16:52:12 <derpy_bridge> [keybase] <seddd>: boldsuck lel, good nym
16:52:25 <sarang> seddd: what are you talking about?
16:52:39 <derpy_bridge> [keybase] <seddd>: AOS signature?
16:52:50 <sarang> Yes, see the paper for citation and description
16:53:22 <derpy_bridge> [keybase] <seddd>: sarang: nothing, some keybase user
16:53:34 <derpy_bridge> [keybase] <seddd>: will do
16:54:02 <sarang> I wonder about the generality of their results, since the use of variable generators in the "pass to ring signature" step isn't universal
16:54:30 <sarang> With a fixed generator it doesn't seem to be a problem
16:54:38 <sarang> but then you run into the tracing issue that they wish to avoid
17:05:22 <derpy_bridge> [keybase] <seddd>: So in AOS they are using variable 'g' with every ring dig? Not sure I understand
17:05:33 <derpy_bridge> [keybase] <seddd>: sig*
17:09:01 <derpy_bridge> [keybase] <seddd>: need to read the revisions
17:10:14 <sarang> Looks like they use a per-index generator `G + e_1*H(P_i)` at index `i`
17:10:20 <sarang> Which works for AOS, but not for AOS'
17:10:43 <sarang> So their Appendix C variation does not work in the general ring-signature case if you use the required variable-base key image
17:10:55 <sarang> I suspect this means the security proofs won't hold in general for the Appendix C variation
17:11:00 <sarang> But I've written to the authors to ask about this
17:11:20 <sarang> And there's no way that the AOS variant (which does appear to work) would be more efficient than CLSAG in verification anymoore
17:11:24 <sarang> *anymore
17:11:47 <sarang> Hmm, although maybe I'm speaking too soon
17:11:59 <sarang> Since you'd only have a single multiexp operation in each hash operation
17:12:18 <sarang> I should code it up and see
17:12:36 <sarang> It'd probably require a new security analysis to show the desired properties
17:12:46 * sarang will stop making these hypotheses...
17:13:07 <sarang> Might be worth coding the AOS variant to see
17:13:36 <sarang> The AOS' variant had the advantage of being parallelizable, which would have been pretty nice
17:15:29 <derpy_bridge> [keybase] <seddd>: parallelizable codes always nice :)
17:15:45 <sarang> Unfortunately that's the variant that doesn't work with variable generators :/
17:16:26 <derpy_bridge> [keybase] <seddd>: will re-read the clsag paper for comparison on what these authors are trying to do
17:18:08 <sarang> Their idea was was to generalize the multi-dimensional key vector idea so it could add linkability to different non-linkable ring signature constructions
17:18:26 <sarang> and then you could choose the ring signature that provided the efficiency you want
17:18:44 <sarang> A neat idea, but it seems to break down without a fixed-base key image (except in select cases, like AOS)
17:20:13 <sarang> Their fixed-base AOS variant showed (according to their data) a lot of of improvement over CLSAG for verification times, but it's not clear how much of that was because of the removal of per-index public key hashes, which you need in the variable-base case
17:29:47 <sarang> Doing a quick modification of the CLSAG test code should show what the actual verification difference is for the AOS variant
19:06:56 <sarang> Do folks want to have a research meeting this Wednesday as usual, or ought we cancel it due to ongoing crazy world circumstances?
19:45:42 <gingeropolous> thisisfine.gif . not that I usually provider more than silly exclamations, but ..... i enjoy the meetings, and appreciate efforts towards relative normalcy.
19:46:40 <sarang> I'm fine either way. I assume that there will be generally less to share overall, since folks may need time to take care of themselves, their families, and their communities
19:46:57 <sarang> I plan to be around regardless FWIW
19:47:09 <sarang> (barring any unexpected circumstances)
19:48:38 <sarang> Until then, I'll be working on peer review for IEEE, as well as continuing investigation of the IACR 2020/333 preprint update
19:49:18 <sarang> My initial estimates suggest that 2020/333 has competitive performance with CLSAG, so I'd like to dig deeper on that
20:20:19 <gingeropolous> oh churning. https://old.reddit.com/r/Monero/comments/fnhm6u/maam_monero_ask_anything_monday_march_23_2020/flajvf2/
22:37:41 <sarang> Huzzah, IEEE review complete