1

Reading the following question/answers:

Both say that after the 04 extra type byte is a varint of the count of extra public keys.

But looking at this transaction, the extra field is:

014ead13075e025b64ae67567b4f23e5814ba75997ab84623003cb131a8120ab8b044ead13075e025b64ae67567b4f23e5814ba75997ab84623003cb131a8120ab8b

My attempt at parsing it:

01 4ead13075e025b64ae67567b4f23e5814ba75997ab84623003cb131a8120ab8b
04 4ead13075e025b64ae67567b4f23e5814ba75997ab84623003cb131a8120ab8b

I see the TX_EXTRA_TAG_ADDITIONAL_PUBKEYS byte but there's no count varint.

What am I doing wrong / misunderstanding?

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
wad
  • 21
  • 1
  • 1
    If you ask your code to process a few thousand transactions, how many are you seeing with a 04 tag which then omits the varint? Since txextra is not validated by nodes, it's possible that people are experimenting with creating their own transactions and have made mistakes in their construction of the txextra field – knaccc Feb 19 '22 at 03:52

1 Answers1

2

Quite why you can have a TX_EXTRA_TAG_ADDITIONAL_PUBKEYS without a count I'm not clear on (it surely wasn't created by an official Monero wallet). But if you read the byte and it's less than 64, you can assume it's the count.

It's worth noting, the format used for the extra field is not enforced by the network, hence a wallet not conforming to the format as used by the official wallet, can put whatever data in whatever format they like into the field. Of course in doing so, they risk the transaction not being parsable by an official wallet.

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • And how many high bits exactly should i check? Because i see other transactions with 32 additional public keys, for example: https://xmrchain.net/tx/2a9a920e7ba2bd19a40e630345a069765edc4d86065ec9b15839e389e345b077 – wad Feb 18 '22 at 17:58
  • 1
    If you read the byte and it's less than 64, I believe you can assume it's a count. I've updated the answer, but in looking at the code (the portable binary serialization is really hard to decipher), it's not obvious how you get a TX_EXTRA_TAG_ADDITIONAL_PUBKEYS without a count. – jtgrassie Feb 18 '22 at 20:58
  • 1
    Thank you, seems checking mask 0xC0 works for all transactions. – wad Feb 19 '22 at 07:25
  • 1
    @wad Using that mask may work, but it's only luck that it works. I assume there are very few transactions malformed in this way. The real answer is probably that it is an invalid txextra field, rather than that you need to use a mask. – knaccc Feb 19 '22 at 11:16
  • 1
    @wad I'm with knaccc on this. If you look at that tx with the missing count, the additional pub key is the same as the tx pub key, so it's probably someone's mistake in construction. Now, as tx extra is not a strictly enforced format, parsing in Monero can still work if someone makes a mistake like this. – jtgrassie Feb 19 '22 at 13:40
  • 1
    @jtgrassie great spot, yes it is definitely an erroneous txextra then – knaccc Feb 19 '22 at 13:50
  • Erroneous or not, thay are in the blockchain, and should be serialized and desierialized exactly as they are, or their hashes will not match. I don't like idea of saving bulk transaction without checking everything. – wad Feb 19 '22 at 14:19
  • @wad anyone can put whatever they like in tx extra. It is not a protocol enforced format. – jtgrassie Feb 19 '22 at 14:28