He suggested that the proposer creates two transactions: the CoinJoin transaction and another encrypted 1-to-1 transaction that spends their output to another of their key. When the receiver accepts the proposal, they can create their own 1-to-1 transactions spending their tweaked output to pure bip32 derived keys. The proposer and receiver could then broadcast the CoinJoin transaction and their corresponding 1-to-1 transactions together. This would result in the receiver having only bip32 derived outputs. However, AdamISZ, who responded to the email, stated that he inclined not to add this complexity due to cost implications and said that it would be way more complicated than what they were considering at the moment. AdamISZ also discussed the watch-only issue in CoinJoin transactions, stating that the key tweak (c as per draft BIP) must be known by both the Proposer and Receiver but not by anyone else. The classic watch-only use case of monitoring a wallet in real-time with no private key access is incompatible with this. For the recovery process, he suggested a small amount of round-trip communication between the hot wallet and the cold wallet since anyone using SNICKER with a watching-only wallet must regularly interact with their cold wallet anyway to sign the coinjoins. He noted that on-going discovery of addresses is required for many use cases for watch-only wallets. AdamISZ also made some general comments about AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer who should be assumed to be an attacker.