Should be 6a04 per spec

1. Add the Cashtab prefix as an app-wide paramater in the currency object of Ticker.js instead of hard coding it here

2. Let's go with 0x00746162 as the Cashtab prefix, (zero t a b). So, if I'm reading what's going on here correctly, looks like 313030 should be replaced with 00746162 (keep leading zeros to conform with 4 byte standard)

this is asm, not hex, change name to eTokenPrefixAsm

alternatively, check for the hex prefix, 534c50

See example tx: https://rest.kingbch.com/v4/electrumx/tx/data/7443f7c831cdf2b2b04d5f0465ed0bcf348582675b0e4f17906438c232c22f3d

Vs spec: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/etc/protocols.csv

...spec is super confusing bc all the numbers are backwards. i think we'll change that when we document this for ecash, really want something a dev can copy paste.

From spec at https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_return-prefix-guideline.md

However, values pushed on the Script stack are expected to be encoded in little endian. Thus, for a protocol identifier 0x0ABCDE01, the first bytes of the script are expected to be { 0x6a, 0x04, 0x01, 0xDE, 0xBC, 0x0A } where 0x6a encodes for OP_RETURN.

I think it's most readable to split this up a bit. Documentation is so poor for OP_RETURN that this would be helpful for new devs seeing the repo.

So, use these parameters:

opReturnPrefixHex: 6a
opReturnPushDataHex: 04

This is the hex one, call it cashtabPrefixHex

This one is labeled both isCashtabMessage: false and isCashtabMessage: true

Repeated object key isCashtabMessage

Evaluate if its technically feasible to only use the hex values here and ignore asm. If so, lose the asm stuff and go hex only.

Not sure we need this one

Make a new appPrefixesHex: {} object as a child of the opReturn object that, for now, includes eToken and cashtab: , instead of current arrangement with eTokenPrefixHex: and cashtabPrefixHex as separate entries in the opReturn: object

This will make Cashtab more extensible if we see future apps adopting other unique prefixes and wish to parse for those as well.

Desired output here is

6a0400746162

6a = OP_RETURN
04 = next thing on the stack is 4 bytes long
00746162 = cashtab's 4-byte prefix

A couple of issues here.

1. This value should be 04 and not 02 (the number of bytes in an OP_RETURN app prefix, in hexadecimal)

2. Avoid any hardcoding a hex string without any other explanation of what it is here.

I don't think it makes sense to store prefixes for all the possible hex variations of "next thing up is this many bytes". For readability though, it would be better to use a new function, something like getByteCountHex(), where input is a base 10 number and output is required hex string in op code format.

For now...we only need this value to indicate next thing up on the stack is the prefix. So adding opReturnAppPrefixLengthHex: '04' to currency object is good for this diff.

Note that what is left of the message after OP_RETURN + prefix byte count + correct prefix will also include 2 bytes that describe how many more bytes are on the stack

For example, you could have

a048657265206973206120707265747479206c6f6e67206d6573736167652073656e74207769746820436173687461622e20486d2c20746869732076616c69646174696f6e2066756e6374696f6e2069732077617920746f6f20736c6f772e204d6179626520746f6f206d756368206973206265696e672072652d72656e64657265642077697468206576657279206368617261637465723f2049732074686973

Breaks down into

a0 -> next thing on the stack is 160 bytes
48657265206973206120707265747479206c6f6e67206d6573736167652073656e74207769746820436173687461622e20486d2c20746869732076616c69646174696f6e2066756e6374696f6e2069732077617920746f6f20736c6f772e204d6179626520746f6f206d756368206973206265696e672072652d72656e64657265642077697468206576657279206368617261637465723f2049732074686973 -> Here is a pretty long message sent with Cashtab. Hm, this validation function is way too slow. Maybe too much is being re-rendered with every character? Is this

can inspect that tx (sent with prod Cashtab, before this diff landed) here: https://rest.kingbch.com/v4/electrumx/tx/data/de6640fdbd8e1b51e85c20754e9da3227b90c47f11e6714d8948177713a87dd6

Important to note that when this diff lands, it will not correctly parse old Cashtab msgs, because they are not constructed correctly per spec. That's okay. We only want to parse for spec-correct msgs.

The desired output here is

6a0400746162

These need to be updated to reflect corrected prefix above

correct this per prefix corrections above