1

Currently, MLSAG is being applied to each real input, giving one signature per real input. What would the space savings be if it was applied over all real inputs, giving one signature per transaction?

Update:

See zeroToMonero pg41

WeCanBeFriends
  • 660
  • 3
  • 7
  • To propose a new signature scheme whereby you only have "one signature per transaction", you must define how this new scheme will work (how it is constructed, what is the published proof and what is done for verification). Without these details, this question should be closed as it falls into the SE categories of being "too broad" or "primarily opinion-based". Feel free to update the question with more details. – jtgrassie Apr 30 '19 at 00:15
  • It's not a new signature scheme. See zeroToMonero pg41 , where it explains that this was the original scheme to be used with MLSAG, but it was dropped due to the shared index problem – WeCanBeFriends Apr 30 '19 at 08:44
  • Why did you not just write "What would be the space saving of using RCTTypeFull over RCTTypeSimple?" then? – jtgrassie Apr 30 '19 at 10:28

3 Answers3

3

I'll restate your question for clarity:

Currently, it's the case that for transactions with multiple real inputs, multiple RCTTypeSimple MLSAG signatures are used. This is to prevent the leakage of the position of one real input in the ring from leaking the ring position of other real inputs (because they'd all be at the same ring index).

In an m real-input transaction with a ring size of n, what would the space saving be if a single RCTTypeFull MLSAG signature was used to sign the transaction instead of multiple RCTTypeSimple MLSAG signatures? The Zero to Monero paper says:

Our perception is that the decision to limit RCTTypeFull transactions to one input was rather hastily taken, and that it might change in the future, perhaps if the algorithm to select additional mix-in outputs is improved and ring sizes are increased. Also, Shen Noether’s original description in [61] did not envision constraints of this type. At any rate, it is not a hard constraint. An alternative wallet might choose to sign transactions using either scheme, independently of the number of inputs involved. We have therefore chosen to describe the scheme as if it were meant for multi-input transactions.

The space requirement for an RCTTypeFull MLSAG signature is: 32*(n*(m+1)+m+1) bytes of storage for the signature including key images (no pseudo outs are required).

The space requirement for multiple RCTTypeSimple MLSAG signatures is: 32*m*(2*n+3) bytes of storage for the signatures including key images and RCTTypeSimple-only pseudo out commitments.

Therefore, for the examples you gave, for mixin 7 (ring size 8):

1 input: RCTTypeFull = 576 bytes, RCTTypeSimple = 608 bytes. Saving = 32 bytes.

2 inputs: RCTTypeFull = 864 bytes, RCTTypeSimple = 1216 bytes. Saving = 352 bytes.

The savings at our current ring size of 11 are:

1 input: RCTTypeFull = 768 bytes, RCTTypeSimple = 800 bytes. Saving = 32 bytes.

2 inputs: RCTTypeFull = 1152 bytes, RCTTypeSimple = 1600 bytes. Saving = 448 bytes.

knaccc
  • 8,468
  • 16
  • 22
0

Currently, MLSAG is being applied to each input, giving one signature per input.

No. You actually get one MLSAG signature per input ring. The the largest space requirement to the published proof is actually having to include the components ri,j for each input in each ring. These are 64 bytes per input. Thus, the savings are maybe not as big as you think.

In any case, it's hard to define an exact answer to your question without you defining what your proposed signature scheme and proof components are, that would allow for the same verification properties of the currently used MLSAG scheme (RCTTypeSimple).

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • I was not proposing a change to the signature scheme, I was proposing to use MLSAG to sign over all inputs at once. Which would remove the need for pseduoOuts. See zeroToMonero pg41 – WeCanBeFriends Apr 29 '19 at 23:16

  • You actually get one MLSAG signature per input ring\n

    This is what I was stating. Maybe I should have clarified by saying real input

     – WeCanBeFriends Apr 29 '19 at 23:17
  • If you meant each ring or each real input, why did you omit this definition? So your saying you want to create one signature over all rings instead? And you are proposing a change, just not defining it, or it's proof. – jtgrassie Apr 29 '19 at 23:45
  • You can't say things like "Which would remove the need for pseduoOuts" without defining how to verify without them. – jtgrassie Apr 30 '19 at 00:09
  • I have linked to the information I am referring to in the first comment. Where it is mentioned already in the zeroToMonero book. – WeCanBeFriends Apr 30 '19 at 08:47
-1

I'd like to say that if there are n real inputs, it will save n-1 scalars. Since each signature has a c1 scalar. The number of r values(responses) would be the same.

Also we would not have the pseudoOuts, so we would save another n Points. Assuming a scalar and a point are 32 bytes each. Then for n inputs, we would save:

(n + n-1) * 32 bytes = 32(2n-1) bytes

If maths is correct, then:

With 1 input we would save 32 bytes.

With 2 inputs we would save 96 bytes.

With the popular mixin number of 7, we would save 416 bytes.

WeCanBeFriends
  • 660
  • 3
  • 7