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
  "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": [ {
        "mask": "d073ccb38b7e2d0e4cf0cf0ec80189bfd185e78452ae71bff7560cb80da4130e", 
        "amount": "927c6a073deb6030af17876b0e2f2a792e41ad7f8ee2b4f3200bd111818e6e0a"
      }, {
        "mask": "405c21e87c0a34452d4556617cc418820324de2dfaf3db962152ae3d37f80508", 
        "amount": "525f724a967c25be5e85292b8d822ab66e2c256af6861e758ebb500e16c9ad04"
    "outPk": [ "e356a3285a7120d060df871a4a76d0f72550b1c323aa52252001dbff2d5a2fb2", "ca0d7844b052f6183a933dcf97a8a72acd5236d8a7f3c0b93631d5841752b504"]
  "rctsig_prunable": {
    "rangeSigs": [ {
        "asig": "93942a5f22136543...................9b5e651c331a5f1960f", 
        "Ci": "4f08d0a8914f450723685e67....37c77d72f065bbc33157eec194be7a198bb"
      }, {
        "asig": "823405363e57560b334e2........95c9e9c9bc3726d57b4bad29a5d181bc02", 
        "Ci": "c3f62d192372296f50e916cbeef8....7b56e9962e1a660c68fed15d15c8af3"
    "MGs": [ , 
      "ss": [ [ "f36300cd00b463281e31f32f942583800cbbe575028f0edee2a930b3aabbab08", "0acdd75b007bf52f7f7c1747450de2d99fd1a2e31c31fe6924c80bf563572f0a", ], [ "7d4c0e75b5d8aac314a8b8c5d4e54a8f2970bb92c51bdb2bbb1345ad21e3120f""2e8468a158ecf425af93c1db08f9e57be3e85fa1d33f56cef9266ad80b807d0d"], [ "19145dc851c8d79b89cc7eff289c03c583648d467a72143879db13178f5fcf05""4a0465facf45c36e89c7cac6afa0802a43e1fbd772ad7c4df821d45ef3a06c04"], [ "bbc090171e4620f7388f21e5335bff996eebcd22ac8a1b78e0e5dfe00b42600a", "d7e6ba126a9261cb33fa91deb7c179f9a0dc72b3096bc665ed8b06807b913c03", ], [ "4e5910093744557a3db315c8bc00d3422675c37fdbad4ded51ec86e8fa448c00", "b3ef06ad3142baef326ad6e70fda5e6316bb333f6519a9d893009a1d26eb5f05", ]]"c4ed83aef2fa07495da00ecdfecfc585c7f910db10c69e3ff616df1e8cd73403"]

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...".
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)?

2 Answers 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
    Commented Mar 14, 2018 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
    Commented Mar 14, 2018 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
    Commented Mar 14, 2018 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
    Commented Mar 15, 2018 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
    Commented Mar 15, 2018 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
    Commented May 18, 2018 at 17:12
  • 1
    Please answer the question instead of just linking to external papers
    – 254123179
    Commented May 18, 2018 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.