Differential D14381
[ecash-herald] Cleaner OP_RETURN parsing Authored by bytesofman on Aug 16 2023, 23:00.
Details
Some OP_RETURN txs of unknown schema are printed to the channel in an unintelligible way. Many times, assuming an unknown OP_RETURN is ascii can make it readable (existing test vector for unknown tx is like this). Other times, decoding a random non-ascii hex string as ascii creates jargon. Add a function containsOnlyPrintableAscii to determine if a given OP_RETURN hex string contains only non-control ascii characters. If a given OP_RETURN stack array does not, print each push as a hex value. npm test
Diff Detail
Event TimelineComment Actions Would that prevent memo strings with emojis?
Comment Actions It's only being applied on "unknown" OP_RETURN txs -- i.e. OP_RETURN txs that do not include a protocol identifier understood by ecash herald. memo txs have a parsed protocol identifier and are handled separately in parseOpReturn and parseMemoOutputScript. Memo txs that Cashtab has not been programmed to handle print Unknown memo action. So -- if a memo tx is not properly prefixed as a memo tx per memo spec, it could be caught as an unknown tx. In this case, it would be rendered either as ascii parsed if it happened to only contain ascii characters (wrong for memo, which is utf8, though would probably appear mostly intelligible) -- or as a string of hex values prefixed by 0x and separated by a space if any values were non-ascii. imo an improvement over the current app which will just treat it as ascii no matter what. Comment Actions On second thought ascii is probably not what you want, you want it to be printable and human readable. so 32 <= byte <= 126 (plus maybe CR and LF) | ||||||||||||||
