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?

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
    Commented Feb 19, 2022 at 3:52

1 Answer 1

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.

8
  • 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
    Commented Feb 18, 2022 at 20:58
  • 1
    Thank you, seems checking mask 0xC0 works for all transactions.
    – wad
    Commented Feb 19, 2022 at 7: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
    Commented Feb 19, 2022 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
    Commented Feb 19, 2022 at 13:40
  • 1
    @jtgrassie great spot, yes it is definitely an erroneous txextra then
    – knaccc
    Commented Feb 19, 2022 at 13:50

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.