[Cashtab] Full refactor of the OP_RETURN parsing logic to revolve around bytecounts
Summary:
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 the base16 hex into base 10 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 transaction type (i.e. Cashtab message, external message, eToken)
>index 1 for the actual cashtab message
>index 2...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.
Test Plan:
- npm start
- send a long and short message to wallet from within cashtab
- send a long and short message from electrum
- send an eToken transaction
- ensure no unexpected symbols in all instances and that source specific labelling is shown (e.g. cashtab vs external message label)
Reviewers: bytesofman, #bitcoin_abc
Reviewed By: bytesofman, #bitcoin_abc
Differential Revision: https://reviews.bitcoinabc.org/D10628