# Understanding MLSAG in Monero transaction

This is a followup question to Understanding the structure of Monero transaction with emphasis on the MLSAG part.

Here's the transaction's structure again given with print_tx 3cf34714d411d051722ec32990bf46567c7ae3432871f75f58005cb6b5b3021e:

Found in blockchain at height 817804
020001020005878c01c451a40.....................f910db10c69e3ff616df1e8cd73403
{
"version": 2,
"unlock_time": 0,
"vin": [ {
"key": {
"amount": 0,
"key_offsets": [ 17927, 10436, 804, 32, 3817
],
"k_image": "67e33ecb9fc4e697248ef57ca88aa626fe670ce1551598f9cbc1565089d43c41"
}
}
],
"vout": [ {
"amount": 0,
"target": {
"key": "7787bbef1a35b936e439aee4ae97cc245ba55ef35186efa3e9e86076a8fba1a6"
}
}, {
"amount": 0,
"target": {
"key": "f981817b20f7a866abb6a9cb29e8062a16fb15f11f0a20c0f0f296eb26e1eab1"
}
}
],
"extra": [ 1, 243, 27, 110, 49, 81, 52, 210, 213, 88, 152, 180, 126, 8, 156, 71, 33, 198, 169, 160, 109, 195, 45, 169, 137, 191, 32, 88, 36, 226, 210, 123, 115
],
"rct_signatures": {
"type": 1,
"txnFee": 26000000000,
"ecdhInfo": [ {
}, {
}],
"outPk": [ "e356a3285a7120d060df871a4a76d0f72550b1c323aa52252001dbff2d5a2fb2", "ca0d7844b052f6183a933dcf97a8a72acd5236d8a7f3c0b93631d5841752b504"]
},
"rctsig_prunable": {
"rangeSigs": [ {
"asig": "93942a5f22136543...................9b5e651c331a5f1960f",
"Ci": "4f08d0a8914f450723685e67....37c77d72f065bbc33157eec194be7a198bb"
}, {
"Ci": "c3f62d192372296f50e916cbeef8....7b56e9962e1a660c68fed15d15c8af3"
}],
"MGs": [ ,
}
}


Now, I see ss as a 2X5 matrix of s values according to RingCT paper, page 11 in the middle, "The signature is then given as...".
Questions:
1. What is the actual structure in this case of R (the matrix to sign on)?
My understanding is that it's a matrix of 5 rows, each row j of the form:
${P_j, P_j + C_j - \sum_{i} C_{i,out}}$
2. Don't we need 2 private keys (x and x+z as detailed in section 4 of the paper)? In that case, to fit the MLSAG scheme, don't we need another linkability tag in addition to the single key image (i.e., I_2)?

Page 11 in that paper is still only concerned with the general ring signature case, not particularly focused on the Pedersen Commitment part.

The MGs field corresponds to the struct mgSig in src/ringct/rctTypes.h:

typedef std::vector<key> keyV; //vector of keys
typedef std::vector<keyV> keyM; //matrix of keys (indexed by column first)
struct mgSig {
keyM ss;
key cc;
keyV II;
};


In this case, ss is a matrix of 2 rows and 5 columns, and two entries in each j-th column are (P_j, C_j - \sum_{i} C_{i,out}). II corresponds to the key images.

To answer your question 2., yes, we do need two secret keys x and z, for the output public key P_s = x*G and its corresponding commitment part C_s - \sum_{i} C_{i,out} = z*G, respectively. We don't need the second key image corresponding to z, because the output public key P and its commitment C are always coupled, so double spend checking using just one key image suffices.

• Regarding question 2: I understand that we do not need another key image for Link, but as far as I understand from MLSAG description section 2.2 ("The signature is then given as..."), we still need (I_1, ..., I_m) for the Verification part (in order to compute R_j for each j) – oleiba Mar 14 '18 at 6:28
• Those (I_1, ..., I_m) are key images, and of course are needed to prevent double spends. In the above example with a single input (m=1), the key image is I=x*Hp(x*G). I interpreted your question as whether one also needs to use another one J=z*Hp(z*G) corresponding to the commitment part, and the answer is no. – stoffu Mar 14 '18 at 8:15
• Yes, you interpreted the question perfectly, I ask whether one needs to use another one J=z*Hp(z*G). Can you explain why the answer is no? it seems vital to be able to calculate the R_j's in the MLSAG scheme. – oleiba Mar 14 '18 at 11:39
• R is needed only for checking double spends. Double spend checking is already done using the first one I=x*Hp(x*G), so there's no point in doing it again with J=z*Hp(z*G) because the secret keys x and z are always coupled; i.e. they're never used separately. – stoffu Mar 15 '18 at 1:00
• I'm sorry, I'm still missing something. The LSAG "Veirfy" algorithm explicitly says: "An observer computes Li , Ri, and ci for all i and checks that cn+1 = c1. Then the verifier checks that ci+1 = h (m, Li, Ri) for all i mod n". So - he must calculate Ri for each i, which needs the tag I, in order to verify the validity of the transaction. – oleiba Mar 15 '18 at 12:48

A detailed breakdown of the various components of a Monero Transaction can be found in section 5 of ringCT (or pdf version if you prefer). It includes an explanation of the "rct_signatures" and "MGs" fields. To better appreciate it though, it is recommended to understand the logic and modus operandi of MLSAGs and Confidential Transactions. This should help you out: MLSAG (or pdf version) and CT (or pdf version)

• Thanks for answering. If you see, I have references to that same paper in the question itself. I have an issue with some specifics in this scheme implementation in Monero. – oleiba May 18 '18 at 17:12