The old parser had to deal with pushdata. So, while it did "work," it was hardcoded to only parse memo txs that were pushed with '02'

memo is unique in that the prefix is '6d' (1-byte) , but it is always pushed with '02' because there are many different actions. e.g. 026d01 means this tx is a memo tx that is setting name, 026d02 means this tx is posting a memo, etc.

The parse memo function will need to be refactored to take advantage of the improvements available with consumeNextPush but for now I didn't touch it.

02 needs to be removed here because consumeNextPush does not return pushdata, just the push itself. Better since now we could parse memo txs with the prefix pushed differently, tho I haven't seen any of these.

Previously, we were getting prefixes by checking hardcoded initial characters. So, memo was differentiated as having a 2-byte prefix.

Now we just get the protocolIdentifier as the first element of stackArray.

For memo, the first push is always different depending on the action. So, it will be 2 bytes and start with 6d, e.g. 6d01, 6d02, etc -- it's not like other protocols where the first push is simply the 4-byte identifier and always the same.

hm good point. Basically any attempt to just spit out an attempted parsing of an unknown OP_RETURN will likely have some weird characters, general failures. At the same time, this type of parsing is more human-readable than the hex.

Block explorers do it this way even though it might not look great. The failure mode is to just print some nonsense characters, it doesn't throw an error.