An issue recently popped up that required a review of notarization OP_RETURNs between chains. As I hadn’t gone through that code as yet, it was a good time to jump in.
NOTE: Consider this entry a DRAFT, as there are a few areas I am still researching.
Preamble
For notarizations, the OP_RETURN will be a 0-value transaction in vOut position 1. vOut position 0 will be the transaction that contains the value.
The scriptSig of the vOut[1] will start with 6e, which is the OP_RETURN opcode. Immediately after will be the size, which will be a value up to 75, OP_PUSHDATA1 followed by a 1 byte size for values over 75, or OP_PUSHDATA2 followed by 2 bytes of size for numbers that do not fit in 1 byte. And then the “real” data begins.
Block / Transaction / height
The next 32 bytes is a block hash, followed by 4 bytes of the block height. This should correspond to an existing block at a specific height on the chain that wishes to be notarized.
If the chain that wishes to be notarized is the chain that we are currently the daemon of, the next 32 bytes will be the transaction on the foreign “parent” chain that has the OP_RETURN verifying this notarization. <– Note to self: Verify this!
Next comes the coin name. This will be ASCII characters up to 65 bytes in length, and terminated with a NULL (ASCII 0x00). Note that this is what determines if the transaction hash is included. So we actually have to look ahead, attempt to get the coin name, and if it doesn’t match our current chain, look for the coin name 32 bytes prior.
Sidebar: What are the chances that the same sequence of bytes coincidentally end up in the wrong spot so we get a “false positive” of our own chain? Answer: mathematically possible, but beyond the realm of possibility.
MoM and MoM depth
The next set of data is the MoM hash and its depth. This is 32 bytes followed by 4 bytes, and corresponds to the data in the chain that wishes to be notarized.
Note that the depth is the 4 byte value filtered with “& 0xffff”. I am not sure why just yet.
CCid Data
Finally, we get to any CCid data that the asset chain that wishes to be notarized includes. The KMD chain will never include this when notarizing its chain to the foreign “parent” chain (currently LTC).
CCid data contains a starting index (4 bytes), ending index (4 bytes), an MoMoM hash (32 bytes), depth (4 bytes), and the quantity of ccdata pairs to follow (4 bytes).
Afterward is the ccdata pairs. which are the height (4 bytes), and the offset (4 bytes).
Additional Processing
If all of that works, and we are processing our own notarization, the komdo_state struct and the komodostate file is updated with the latest notarization data.
Resources:
To follow along, look for the komodo_voutupdate function within komodo.cpp.