For values that have specific roles in OP_RETURN, let's use them

https://en.bitcoin.it/wiki/Script

e.g. here:

So, let's call it opReturn.opPushDataOne instead of opReturn.longMessagePrefix

I think it's worth doing a bigger refactor here

Right now, workflow from useBCH.js lines 156-186

if (isEtokenOutput(hex)) {
                        // this is an eToken transaction
                        tokenTx = true;
                    } else if (isCashtabOutput(hex)) {
                        // this is a cashtab.com generated message
                        try {
                            substring = extractCashtabMessage(hex);
                            opReturnMessage = Buffer.from(substring, 'hex');
                            isCashtabMessage = true;
                        } catch (err) {
                            // soft error if an unexpected or invalid cashtab hex is encountered
                            opReturnMessage = '';
                            console.log(
                                'useBCH.parsedTxHistory() error: invalid cashtab msg hex: ' +
                                    substring,
                            );
                        }
                    } else {
                        // this is an externally generated message
                        try {
                            substring = extractExternalMessage(hex);
                            opReturnMessage = Buffer.from(substring, 'hex');
                        } catch (err) {
                            // soft error if an unexpected or invalid cashtab hex is encountered
                            opReturnMessage = '';
                            console.log(
                                'useBCH.parsedTxHistory() error: invalid external msg hex: ' +
                                    substring,
                            );
                        }
                    }

So what we have right now is: if it's a token, do something, else if it's a cashtab tx, do something, else if it's something else, do something

Instead, it should be

if token, do something; else, parse it

So instead of having different functions extractExternalMessage and extractCashtabMessage, there should just be one function, parseOpReturn

parseOpReturn should iterate through the OP_RETURN hex message from beginning to end (left to right).

1. pop off first byte 6a
2. Get byte count for first message (If second byte is 4c, then third byte is byteCount, otherwise second byte is byteCount)
3. Parse first message (however many bytes byteCount told you to expect). If first message happens to === 4 bytes and there is a message after it, then the first message is an app prefix, flag it as such
4. Get byte count and msg for 2nd through nth msgs, adding double line breaks between them
5. Match the prefix with anything that may be in appPrefixesHex; if no matches, display it as Unknown Prefix <prefix>

Some unit tests that parseOpReturn should pass:

1. Return a Cashtab message with Cashtab Message flagged and no leading '?' for a message without the 4c byte
2. Return a Cashtab message with Cashtab Message flagged and no leading '?' for a message with the 4c byte
3. Return a message with a valid 4 byte prefix flagged with that prefix, so 0x0x0x0x Message instead of Cashtab Message
4. Return a 4 byte message that is not a prefix as a prefixless 4 byte msg ("External Message")
5. Return a prefixless 0-3 byte message
6. Return a prefixed 0-3 byte message
7. Return an n-part message that has multiple byte counts, for example a message that for whatever reason is constructed like

6a + 04 + validPrefix = 0x0x0x0x + 4c + here comes a 21 byte msg + 21 byte msg + 4c + here comes a 16 byte msg + 16 byte msg

For now, parse this type of thing as a double line break, so the above would look like

21 byte msg <br /><br />
16 byte msg

I'm not sure on the purpose of this. We do not want to be appending arbitrary prefixes. If the app has no prefix or if the app has a prefix that Cashtab does not recognize, then it is an unknown app. But we don't want to modify the hex string of that message.

Should confirm the first byte is indeed 6a. I'm not aware of possible exceptions, but might as well throw them out here; can just do this check in the same pre-validation function above, returning false if first byte is not 6a (indicating the string is not an OP_RETURN msg so parsing should not happen).

In this case, the eToken prefix is the Protocol ID --- I'm not sure what index 0 is reserved for

Shouldn't it be resultArray[0] = currency.opReturn.appPrefixesHex.cashtab ?

Please explain the parsing logic, I'm missing something here.

Unclear why this is [1] and not [0]

To improve code readability, create a variable for msgByteSize * 2

i.e.

let msgCharLength = 2 * msgByteSize
hexStr = hexStr.slice(msgCharLength)

This prefix no longer exists, unit tests need to be refactored

Shimming in these <br/> html tags is going to create issues when the app attempts to render in Tx.js

Would be pretty involved to actually get this double line break rendered. So, don't worry about it in this diff. If and when we have apps out there that use this often, we can create a task to handle better rendering.

For now, use something that can be just stuck into the string as a visual cue. Maybe [_]

To test it, could try parsing some eToken transactions. You'll need to modify the function to actually parse the tx in local testing. See that they are rendered in tx history like SLP[_]SEND[_]XXX ...

hm let's get rid of this, don't need the same value saved in two different ways here. opReturnAppPrefixLengthHex is more descriptive, so keep that one

This is converting from hex (base16) to decimal (base 10); correct the comment

Same comment issue

I said let earlier but this should be const

Should only be checking for prefix matching if i === 0

Should only be checking for prefix matching if i === 0

These unit tests should test against the entire returned array, and not just individual indices from it. It's confusing for code readability and limiting the domain of the unit test.

Please include mock outputs of resultArrays