The sender proposes a solution where the proposer creates a coinjoin-tx, along with another tx encrypted with a shared secret, which is a 1 input-1 output (1to1) tx that spends his output to another of his keys. When the receiver accepts the proposal tx, they could create other tx 1to1 which spend their tweaked output to pure bip32 derived key and then broadcast together the coinjoin tx and for every output of the coinjoin tx one other tx which is a 1to1 tx. This strategy ensures that the wallet initial scan does not need to be modified. Adam's response describes the key tweak as c and how it must be known by the proposer and receiver but not anyone else. Therefore, classic watch-only use cases where you monitor a wallet in real-time with no privkey access is incompatible with this. However, for monitoring in real-time as new SNICKER transactions arrive, the c values can be sent from the hot wallet to the cold wallet without changing the cold's security model. Adam also mentions some general comments such as Elichai's comment on the draft regarding AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer who should after all be assumed to be an attacker. He concludes by saying that the discussions so far have been very useful.