It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (c as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The c values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak c must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending c values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak c must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation.