Understanding the structure of a Monero transaction

Question

So I am trying to understand how Monero works under the hood, and I was looking at the transaction below. (If you would like to see it in your own daemon, switch to testnet and just type print_tx 3cf34714d411d051722ec32990bf46567c7ae3432871f75f58005cb6b5b3021e) I would like to know what some of these fields mean. (I know that what follows might be seen as many questions, but you can view them as optional sub-questions to the main question: How is a Monero transaction structured?) Any insight on any of these parts, or how they are related would be greatly appreciated. For example:

1) What are the numbers inside "key_offsets"? The size of that vector seems to change according to the mixin chosen, so I assume that those numbers are a way to refer to the outputs involved in the ring signature, but what is it? I mean, clearly they aren't transaction ids,and it doesn't seem like they are block heights either.

2) What is the field "extra"?

3) Inside "rct_signatures", it says "type": 1. What is that, are there other types?

4) I assume that "mask" and "amount" are x and a in the Pedersen commitments as defined in the RingCT paper: C(x,a) = xG + aH. Is that correct? (Edit: as noted by Luigi in the comments, "mask" and "amount" are not x and a themselves which are kept secret on the blockchain, but are encrypted as x'=x+s1 and a'=a+s2 where s1=Hs(d), s2=Hs(s1) and d is the shared secret rA=aR between the sender and receiver.)

5) Why is there a field called "rctsig_prunable"? Is that some information that can be discarded later?

6) What are the fields "asig", "Ci", "MGs" and "ss"?

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": [ {
        "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"]
  }
}

Answer 1

Key offsets are the set of outputs your ring is using as "fake"outputs, as well as yours. Outputs of a given denomination are ordered in blockchain order, and thus can be represented by their index in that list. This is smaller than using the public key. Moreover, they're stored as offsets from the previous one (the first one from 0), as this will result in smaller values, which can often result in a yet smaller amount of data, since those numbers are written out in a variable length output (kinda like UTF-8 in rough outline).

Extra is a grab bag of metadata. Typically, it will include the public key R for that transaction's one time key. It can also include an "extra nonce", which is used for the payment id, if the transaction has one. There are other things that can be put in there, including user defined data if so wanted.

Type 1 for ringct signatures is a particular way of laying the signatures. Type 1 and 2 exist. Type 1 is the original algorithm, and only works if all the real inputs are at the same index in all rings in that transaction. Obviously, it leaks information on the real inputs, so it's only used for single ring transactions, where this drawback does not matter, and it is slightly smaller than type 2. Type 0 means there are no signatures.

Mask and amount, I believe you are correct.

The rctsig_prunable field is the part of the RingCT signatures that can be pruned later, that's right. There is no pruning yet, just tidying up so that future pruning can be done with less changes.

I don't know the specifics for the remaining fields, but MGs are the MLSAGs, the overall signatures over the rest of the transaction and rct data.