2

Extending this question I am interested in parsing the TX_EXTRA_TAG_ADDITIONAL_PUBKEYS.

Here is how the extra looks like:

ix   value byte
  0     1  01
  1    73  49
  ...
 32   230  e6
 33     4  04
 34     4  04
 35    35  23
 36   167  a7
 ...
161    86  56
162   148  94

where ix is the 0-based index of the particular byte/value in the extra part. In total there are 163 bytes.

First byte (index 0) means next 32 bytes will be the transaction public key (R in the cryptonote paper). This moves us onto position 33 which is where the TX_EXTRA_TAG_ADDITIONAL_PUBKEYS starts. Next byte is \x04 which,I assume, is as a varint telling us that there are 4 extra pubkeys (we know each is 32B). This means we stop parsing at position 162 (the last byte of the extra field).

This seems to make sense, but I'd like to double check that it's the correct way to parse it.

For the sake of completeness here is the whole hexlified extra field (block 282032, transaction 1 on current stagenet)

0149fa9fbadf1c1a4d054c6cbf918778f869ad02103501d8da7eec8762eb2202e6040423a7b09c4078f5c9ea571e3db6e5406de7c27f5e9ec27c84575ce7ad247baf03c9b9152925ec1a3cb3afde3ba43d42581f032bfd39badb178058f654c74b860df4f3a6d5c3bd7abf9b4c183c5db3d4ae34cd2ebfe77be112ff28f869dc2e560035136f206595a6777ba3be8eda6baf036d425fffe0b8678c4ca5cc853f705694
Improve this question

1 Answer 1

Reset to default
4

The structure of your whole extra field is:

01 - TX_EXTRA_TAG_PUBKEY (1 byte)
49fa9fbadf1c1a4d054c6cbf918778f869ad02103501d8da7eec8762eb2202e6 - the tx pubkey (32 bytes)
04 - TX_EXTRA_TAG_ADDITIONAL_PUBKEYS (1 byte)
04 - the number of tx additional pubkeys that will follow (varint)
23a7b09c4078f5c9ea571e3db6e5406de7c27f5e9ec27c84575ce7ad247baf03
c9b9152925ec1a3cb3afde3ba43d42581f032bfd39badb178058f654c74b860d
f4f3a6d5c3bd7abf9b4c183c5db3d4ae34cd2ebfe77be112ff28f869dc2e5600
35136f206595a6777ba3be8eda6baf036d425fffe0b8678c4ca5cc853f705694
 - the 4 additonal tx pubkeys (32 bytes each)

Note that if you try to parse the tx extra tag and it is 00, that is padding and you can skip forward a byte. If it is anything other than 00, 01 or 04, then after you read the tag, read a varint next, and then skip that number of bytes (as indicated by the varint) to get to the next tx extra tag id to read.

The varint integer representation is defined in section 1.2 of https://tukaani.org/xz/xz-file-format.txt

Improve this answer
2
  • Will it read a 1 byte varint, or follow the varint representation and collect bytes until a byte with the most significant bit equal to 0 is found (or until 8 bytes have been collected, since that's the max size of a Monero varint)?
    – koe
    Commented Jan 6, 2020 at 10:53
  • 1
    @koe The point of varints is that you don't need to know the number of bytes in advance, you just read until you get the byte with the zero significant bit. I'm not sure exactly how it's implemented in the C codebase, so I can't comment on whether there is a max size.
    – knaccc
    Commented Jan 7, 2020 at 0:24

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.