Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Shorter MLSAGs with Hidden Amounts #52
It is my understanding that right now the Monero MLSAG signature contains two sequences of scalars. Their use is to separately and respectively ensure linkability and that the commitments for the amounts add up to zero. (I am basing my understanding from posts about ringCT (e.g. here), and although I am aware that Monero now uses Bulletproofs, I believe that the MLSAG part should still be the same, since, to my knowledge, bulletproofs integration only affected the range proofs.)
So, to recap and make sure that I got the right picture, this is what I think goes on now:
Signer picks a ring of outputs that includes his own output, plus decoys. The simplified ring information needed for signing looks like this:
(WLOG and to simplify the exposition, we assume that his output is at position
Next, he picks two sequences of random scalars:
Finally, he sets:
Verifier parses the signature information and computes, for
If that understanding is correct, I am wondering if that signature cannot be made shorter by completely eliminating the
The Naive Approach and the problem with it:
The naive approach would be to just add
This naive approach already has the advantage of passing the corresponding verification for an honest signer and having a shorter signature. However, it also has a big problem: since the verifier has no way to check that
Solution: Use a Linear Combination with Hashed Coefficients:
To fix that, before redefining
Then he proceeds to define:
and, for each
Finally, he sets:
This way, the honest signing still passes the corresponding verification, but any attempt to find
This signature format change would incur only the additional computational cost of two
[Edit: I had forgotten to add
This is actually a neat way to map a many-rowed MLSAG ring signature scheme to a single-rowed LSAG signature scheme. I like it. I would want a tight security proof before moving on implementation, but I don't think that proof would be too difficult... What I find interesting about this is that this introduces a sublinearity in signature sizes... if we want to sign with a length-n vector of keys in a ring signature with R members, we can do so for the same space as a length-1 vector of keys, although verification time increases requisitely.
I hadn't thought about how to aggregate different rings from an MLSAG together, just their hidden amounts component. It is an interesting idea. Aggregating public keys that don't need to be linked, like commitments to zero in this context, seems less complex than adding ones that do need to be linked, like other one-time addresses.
I have been trying to aggregate two rings of signing keys together the same way the amount commitment component was aggregated, but so far I haven't been able to. I suspect we may not be able to do that as seamless as the amount case, or at all. The reason is this: for the amount case,
If we take two points and their respective key images
Consider, however, that the reason that the key image is not linkable to the signing keys is not because of the use of
With that in mind, if we fix an independent point
So, for instance, a regular linkable ring signature would look like this:
and, for i in [1,n]:
With this change, we could get a ring signature whose size depends only on the ring size, but not the number of rings.
I also find the scheme sound.
For your second proposal, I find the idea of fixing the basepoint for key images workable as well, but I think it means that the signer's index has to be the same for all the rings, which I think is undesirable (AFAIK this is why RCTSimple type with pseudo outputs was introduced).
@stoffu I share your concern. Probably the trade-off between compressing all signing keys at the expense of linking the indices is not a good one, and just aggregating the amounts may be good enough for now.
Fixing the base point
So right now I believe that changing the key image but not aggregating signing keys would allow for faster verification times and smaller signatures (compared to present ones, although not quite as the aggregated ones, of course) without compromising untraceability.
Update: in transitioning to the new key image format, new signing and verification algorithms are needed that involve outputs that could have been spent with the previous key image format as well as the new ones. In the following I will outline how such a transition can work.
First a block height
The verifier receives a signature
Therefore, in order to pass verification, the signer will need to produce the signature constructed in the same way.
Signer picks random scalars
Notice that this doesn't require any changes to the output format itself, but only to the signing and verifying algorithms.
Since the points
It's also important to consider the balance between the added implementation complexity and the provided performance benefit. I don't really feel like bringing external data such as the fork height and the output keys creation heights into the basic RingCT functions unless the advantage is very significant (which doesn't seem to be the case to me here).
@SarangNoether asked me to take a look at this issue.
Here are some notes:
Thanks @apoelstra for looking this over. Comments regarding the notes:
@apoelstra Indeed it seems that using the fixed point for the key image may lead to the problem referred to in the Cryptonote 2.0 paper. Thank you for pointing that out!
I will leave it here for others reading the thread. I am paraphrasing from the section 'Notes on the Hash Function Hp', from the Cryptonote 2.0 paper:
If Alice sends two payments to Bob, whose stealth address is
Now, subtracting the two, Alice could check that:
This would give Alice the ability see when those outputs were spent by Bob.