The answer is linearity, a question discussed by the cryptonpte white paper

PoPETs review of Triptych rejected for their conference based on it being incremental and more suitable for a workshop submission :/

Good times

They also wanted a more direct real-world implementation comparison, but I think that's less useful than what was included in the preprint

The ESORICS blockchain workshop deadline is in just a few days, but it could still be a good destination given the scope recommendations

boo :/

I'm definitely not going to code optimized versions of Omniring and RCT3 in exactly the same library as Triptych and Arcturus just for comparison, and trying to extrapolate from implementations elsewhere is basically meaningless

The whole point of looking at operation counts is to avoid all of those things, so I completely disagree with the review on that point

Can't really argue with "out of scope for what we want here"... that's totally up to the editors/reviewers

For Arcturus there's an opportunity to address PoPETs reviewer comments, which tended to overlap those for Triptych

Recommendations for workshop submission (i.e. not general enough, too incremental)

One reviewer provided a supposed counterexample for the cryptographic hardness assumption that doesn't even work (I'm not sure they actually read the entire definition, or tested their counterexample...)

Another reviewer made an interesting point that they considered the possible risk of a novel assumption not to be outweighed by the benefits of the new construction

and that's certainly a reasonable opinion

I mean.. wasn't RingCT implemented without a real security proof?

What do they mean by incremental? I thought Triptych was a new system

UkoeHB_: the MLSAG preprint never underwent formal review AFAIK, and the security model it (and the original LSAG paper) uses are extremely limited compared to more modern stuff

Triptych is new, but it's in some sense an incremental improvement over the original Groth/Kohlweiss proving system that was used for a non-linkable ring signature construction

I happen to think it's a bigger deal than that, because of the useful applications

but that's a matter of opinion, I suppose

FWIW one of the reasons CLSAG took so long to get right was the security model

Getting things right under the assumption of malicious keys can get tricky

It's worth noting that MLSAG almost certainly inherits the new CLSAG security model quite directly, so the fact that it was originally proven secure under a less robust security model shouldn't be an issue in practice

Anyway, I'll make some of the Triptych edits recommended by the PoPETs review, update the document format (what fun), and submit to the ESORICS workshop

I can't do the same to Arcturus since it's still under consideration for PoPETs

Deadline for ESORICS is July 10, which should be plenty of time (he said confidently...)

yay fun! :p

In fact, the more I think about it, the more I think the workshop setting will be more amenable to how the preprint is presented

Namely, as building the security model around an LRS definition, and then presenting the application using the multidimensional version

we shall see