This is an automated archive made by the Lemmit Bot.

The original was posted on /r/monero by /u/c19th-s5 on 2024-07-29 18:52:06+00:00.

Hello all,

I find Monero’s development of a new full-chain signature FCMP++ extremely interesting. It is a replacement for the currently used CLSAG and, according to the FCMP++ specification, is mainly based on the recent cryptographic primitive called Curve Trees.

To my point of view, Curve Trees looks like a fundamental solution that, if successfully landed on Ed25519, can cover not only the need for an efficient signature but also in the long run other demands. However, there is still a question how long the full R&D+audit cycle can take.

Meanwhile, I’d like to say a word about an alternative signature idea from a ‘different weight class’. It probably might be viewed as a minimalistic fallback or a temporary option for the case if the FCMP++ audit is expected to take a long time. Of course, I may not know many factors, anyway, I guess that knowing a possible alternative might be interesting to the Monero community.

I stress that my post is not about which signature is better, nor is my intention to undermine the development of FCMP++. It’s just an announcement that there is another simple efficient ring signature scheme, albeit in the draft stage, that can also replace CLSAG.

The signature idea is called LS-LSAG and described in the draft at . It is built up only of those components that are currently used in Monero and handles Ed25519 in the same black-box way as CLSAG. The draft contains a description how all the three signatures, CLSAG, LS-LSAG, and FCMP++ can drop-in replace each other in an evolving system.

LS-LSAG works with key images that are currently in use in Monero, and also largely follows the existing CLSAG design. It just replaces the CLSAG linear-size proof with a log-size one. The cryptographic assumptions are the same, no trusted setup too.

Due to simplicity of the scheme, no batch optimization is foreseen at the moment, though. Anyway, the verification is not expected to be slower than for the linear-size scheme.

Unforgeability of LS-LSAG follows from the discrete-logarithm assumption and collision-resistance of the currently used hash-to-point function, there is a detailed sketch of a formal proof in the draft.

The LS-LSAG design allows variations. The presented version uses a number of helper generators which are sampled on-the-fly during signing-verification. A version having no generators sampled on-the-fly is also possible, it is quite similar, although requires a more complex unforgeability proof.