This diff builds on the standardized prefix approach in D10628 by introducing a Cashtab encryption prefix prior to the encrypted hex. The encryption prefix flags whether this OP_RETURN message has been encrypted or not.
The eccrypto-js library is used, which is an elliptic curve cryptography library that encrypts and decrypts messages using the same eliptic curve cryptography used by Bitcoin.
End to end encryption summary:
Sender's side
1. Send.js flags to useBch() whether the user wants to encrypt the message or not.
2. If the encryption flag is true, useBCH.js' sendXec() function retrieves the public key corresponding to the recipient's address and then calls on eccrypto-js to encrypt the message based on that public key.
3. The encrypted string is then added to the OP_RETURN script after all the preceding prefixes.
Recipient's side
4. As a routine tx history update, useBCH.js' parseTx() function checks if the message is an encrypted cashtab message, and if so, extract the encrypted string from the output hex, which should match the string from step 3.
5. The eccrypto-js library is then called to decrypt the encrypted message using the recipient's private key. The private key is obtained via wallet.state.slpBalancesAndUtxos.nonSlpUtxos[0].wif
6. If the encryption is successful, the decrypted message is sent up to Tx.js for rendering. Otherwise, it is assumed the user is not authorised to view the message, which is then overwritten by a default "Encrypted Message" placeholder text for Tx.js.
Sample breakdown of [[ https://explorer.be.cash/tx/54c2a292c72f5ff6dd7a657adabb2243fa2e347a74e8109e8c686ac70b8dfe13 | output hex ]]
> 6a = OP_RETURN
> 07 = bytecount
> 656e6372797074 = cashtab encryption prefix
> 4c = OP_PUSHDATA1
> 81 = bytecount
> 041163918bdb0964cd661626bc55cf5ea06254ef5839a2a1d96ac11567808bef3d0139465b677b44325390923c0c6c18b8916b9c0c401a7c26ca0279f7bf3c5c5d05b670b7ae71178ba1aae11f85c69b5d01c9db469c53031c9d371c418a4b403cd185d1524dda6446c22adb7aee935edd415efbafb16cf6bc9e1f3341ee8a9e42 = encrypted message