Proposal for Carrot Transaction Format Changes

[jeffro256]

Carrot will require either a change to the hard format of cryptonote::transaction_prefix or a change to extra field handling.

What transaction data Carrot needs

Per transaction output

Name	Symbol	Byte Size	Same storage as v16
Output pubkey	Ko	32	Yes
Amount commitment	Ca	32	Yes
Encrypted amount	aenc	8	Yes
Encrypted Janus anchor	anchorenc	16	No
View tag	vt	3	No

Note that Carrot expands the per-output size of enotes by 18 bytes from 73 to 91.

Enote ephemeral pubkeys

Carrot transactions, like the previous addressing protocol, needs "enote ephemeral pubkeys" AKA "additional transaction pubkeys" to act as bases for the ECDH sender-receiver secret. There is one enote ephemeral pubkey De per transaction output, except in non-coinbase 2-output transactions, where there is only one total. This is more or less the same as before, as the wallet construction/scanning code already did the 1-transfer-1-change transaction pubkey optimization.

How we could store this data

The most straight-forward way to store the per-output data would be to add the non-amount stuff to a struct like so:

struct txout_to_carrot_key
{
    crypto::public_key key;
    carrot::janus_anchor_t janus_anchor;
    carrot::view_tag_t view_tag;
};

And then add it to the txout_target_v variant, just like how the v15 view tag update did it. We would keep the amount commitments in outPk and encrypted amounts in ecdhInfo, just like they currently are. That way, both coinbase and non-coinbase transactions' output targets would be txout_to_carrot_key, just like how it is now with txout_to_tagged_key.

As for the enote ephemeral pubkeys, there's two main possible pathways we could take: A) put it in extra like how transaction pubkeys are done now, or B) hardcode it into the transaction format. Option A has much easier integration. Option B will be able to save one byte per transaction by skipping the size, since the number of enote ephemeral pubkeys is a direct function of the number of outputs and whether or not the transaction is coinbase. I vote option A since FCMP++/Carrot will add a lot of changes to the format already without new premature optimizations.