Change Details

Long OP_RETURN messages results in an extra '4c' encoding inserted prior to the message, which is causing the '?' symbols on some messages seen in prod. This diff adds an additional check for that 4c encoding via removeIncomingBytePrefix() and if exists it removes the next four encoded characters, otherwise as a short message only two encoded characters need to be removed. Unit tests updated to test both short and long message extraction logic.

The current OP_RETURN parsing logic does not properly parse long messages, where the PUSH DATA 1 byte (4c) is inserted prior to the byte count of the subsequent message. This is leading to extra '?' symbols when the messages are displayed on the frontend. This diff carries out a full refactor of this logic. In Summary: * A single new parseOpReturn function added to Ticker.js which replaces all the previous context specific parsing functions (extractCashtabMessage, isExternalMessage...etc). * This new function iterates through the OP_RETURN hex message from beginning to end (left to right). * The first half of the loop in each iteration checks the bytecount and converts it into base 16 decimal. If the bytecount is '4c', then this is deemed to be a long message where the next byte is analyzed as the bytecount for the subsequent message. * The second half of the loop parses only as far as indicated by the preceding bytecount and extracts the message. * The full parsed results are added to the the resultArray[], which is structured as follows: index 0 for the protocol ID index 1 for the transaction type (i.e. Cashtab message, external message, eToken) index 2 for the actual cashtab message index 3...n for any additional message parts as part of an external protocol. * parseTx() function in useBCH.js then takes this array and passes the appropriate decoded hex messages to Tx.js for rendering on the frontend.

Long OP_RETURN messages results in an extra '4c' encoding inserted prior to the message,The current OP_RETURN parsing logic does not properly parse long messages, where the PUSH DATA 1 byte (4c) is inserted prior to the byte count of the subsequent message. whichThis is causleading theo extra '?' symbols on somwhen the messages seen in prodare displayed on the frontend. This diff adds an additional check for that 4c encoding via removeIncomingBytePrefix() and if exists it removes the next four encoded characters, otherwise as a short message only two encoded characters need to be removedcarries out a full refactor of this logic. Unit tests updated to test both short and long message extraction logicIn Summary: * A single new parseOpReturn function added to Ticker.js which replaces all the previous context specific parsing functions (extractCashtabMessage, isExternalMessage...etc). * This new function iterates through the OP_RETURN hex message from beginning to end (left to right). * The first half of the loop in each iteration checks the bytecount and converts it into base 16 decimal. If the bytecount is '4c', then this is deemed to be a long message where the next byte is analyzed as the bytecount for the subsequent message. * The second half of the loop parses only as far as indicated by the preceding bytecount and extracts the message. * The full parsed results are added to the the resultArray[], which is structured as follows: index 0 for the protocol ID index 1 for the transaction type (i.e. Cashtab message, external message, eToken) index 2 for the actual cashtab message index 3...n for any additional message parts as part of an external protocol. * parseTx() function in useBCH.js then takes this array and passes the appropriate decoded hex messages to Tx.js for rendering on the frontend.