8

As I understand from MRL-0005 (Definition 4.1 in page 9), when creating a RingCT transaction with, say, m inputs, n outputs, and q mixin, the i-th member (where i=0...q) of the ring signature R is constructed using output keys {P[i,j]}, their associated commitments {C[i,j]}, and output commitments {C_out[k]} where j=1...m and k=1...n. Due to the use of key-vector in MLSAG, the signature proves that there is one secret index s such that all of {P[s,j]|j=1...m} belong to the same sender. Even though no observer can tell such s, this seems to me like a slight but certain leak of information about potential links among transactions. Can this information be possibly exploited by future blockchain analysis? Is this a legit concern?

One possible direction for improvement I can think of would be to increase the number of members in R exponentially, ie. |R|=(q+1)^m. For example, in the case of m=2, the (i,j)-th member of R (where i=0...q and j=0...q) would be defined using P[i,1] and P[j,2] along with C[i,1], C[j,2] and {C_out[k]}. This way, it is no longer possible to assume the existance of such s as above. Was this kind of idea already discussed in MRL?

kenshi84
  • 2,485
  • 1
  • 14
  • 33

1 Answers1

8

smooth (and I) expressed concern about this same thing during the implementation. The good news is Shen came up with an alternate construction where one MLSAG is used per input rather than combined (see here and below).

With the new construction the single secret index goes away, and we get a straight improvement on untraceability due to less inputs on average. I don't think the proof for the new construction is published anywhere; that would be a good thing to add to the document.

It also wasn't really compatible with existing Monero transactions in the original form for more than one input, as they reference (and order) inputs by offset rather than by key or arbitrarily.

Luigi
  • 2,472
  • 12
  • 14