T3100

Depends on D13807

Updated encrypted message byte size calculation flow:

• Send.js passes the encryptionFlag to sendXec() in transactions.js
• sendXec() sees the encryptionFlag, generates the encryptedEj (serialized encryption data object) and passes it to getMessageByteSize() in cashMethods to calculate the encrypted msg byte count
• sendXec() passes the encrypted message byte count to generateTxInput() in cashMethods.js to generate the appropriate tx fee

However, The frontend encrypted msg input bytesize validation couldn't follow the same approach because generating the encryptedEj involves an api call to parse the public key, which is not feasible when this frontend byte size validation is triggered on each character input in the message textarea. This is still set per encryptedMsgByteLimit in ticker.js.

Also since we don't facilitate OP_RETURN messages for token sends, and the fact that we're already using the { compressEpk: true } flag in the ecies encryption call, there is no need for the subsequent diffs. This will be the final diff in this stack.

• npm start
• attempt to send an encrypted message more than 127 bytes and ensure frontend validation error is triggered
• send an encrypted message and ensure it is decrypted successfully at the recipient wallet and tx fee reflects the size of the encrypted message
• ensure no regression with unencrypted message txs
• ensure no regression with unencrypted one to many message txs
• ensure no regression with one to one and one to many txs with no message
• ensure no regression with token sends and token creation