Change Details

This is for discussion only - pardon the debug statements and failed test suite. This diff builds on the standardized prefix approach in D10494 by introducing an additional encryption prefix after the protocol ID prefix. In this case, the encryption prefix flags whether this OP_RETURN message need to be decrypted 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. For now this is set to always true for development purposes to get the full end to end encryption/decryption process working first. 2. If the encryption flag is true, useBCH.js' sendBch() 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 a cashtab message, and if so, will now carry out an addition check for the encryption prefix. 5. If it's deemed to be an encrypted string, the preceding prefixes are removed, leaving the remaining encrypted string matching the string from step 3. 6. 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 7. If the encryption is successful, the decrypted message is sent up to Tx.js for rendering. Otherwise, the message is overwridden by a default "Encrypted Message" placeholder text. Notes: - Currently due to bch-api constraints, the public key extracted at step 2 is based on a BCH address. I'm currently countering 'bad private key' errors from the library at step 6 so not sure if is the root cause. - Should the sender be able to see the unencrypted message? As it stands, the code will only allow the recipient to see the message.

This is for discussion only - pardon the debug statements and failed test suite. This diff builds on the standardized prefix approach in D10494 by introducing an additional encryption prefix after the protocol ID prefix. In this case, the encryption prefix flags whether this OP_RETURN message need to be decrypted 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. For now this is set to always true for development purposes to get the full end to end encryption/decryption process working first. 2. If the encryption flag is true, useBCH.js' sendBch() 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 a cashtab message, and if so, will now carry out an addition check for the encryption prefix. 5. If it's deemed to be an encrypted string, the preceding prefixes are removed, leaving the remaining encrypted string matching the string from step 3. 6. 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 7. 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. Notes: - Currently due to bch-api constraints, the public key extracted at step 2 is based on a BCH address. I'm currently countering 'bad private key' errors from the library at step 6 so not sure if is the root cause. - Should the sender be able to see the unencrypted message? As it stands, the code will only allow the recipient to see the message.

This is for discussion only - pardon the debug statements and failed test suite. This diff builds on the standardized prefix approach in D10494 by introducing an additional encryption prefix after the protocol ID prefix. In this case, the encryption prefix flags whether this OP_RETURN message need to be decrypted 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. For now this is set to always true for development purposes to get the full end to end encryption/decryption process working first. 2. If the encryption flag is true, useBCH.js' sendBch() 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 a cashtab message, and if so, will now carry out an addition check for the encryption prefix. 5. If it's deemed to be an encrypted string, the preceding prefixes are removed, leaving the remaining encrypted string matching the string from step 3. 6. 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 7. 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 is, which is then overwriddentten by a default "Encrypted Message" placeholder text for Tx.js. Notes: - Currently due to bch-api constraints, the public key extracted at step 2 is based on a BCH address. I'm currently countering 'bad private key' errors from the library at step 6 so not sure if is the root cause. - Should the sender be able to see the unencrypted message? As it stands, the code will only allow the recipient to see the message.