This scheme suggests that users can CoinSwap as soon as they receive funds, making sending payments as fast as non-CoinSwap on-chain wallets. It requires the user to maintain two internal wallets, a pre-mix wallet, and a post-mix wallet. Unspent funds in the pre-mix wallet are automatically swapped into the post-mix wallet, and when sending funds, coins from the post-mix wallet are spent directly to the payee address. Change outputs go to a new swap immediately instead of going back to the pre-mix or post-mix wallets.The scalability and privacy concerns of Bitcoin are raised in an email exchange between Lee Chiffre and Chris Belcher. Chris explains that his proposed CoinSwap system doesn't break pruning or other resource-saving features, making Bitcoin-with-CoinSwap more scalable than Monero. He also highlights how CoinSwap improves privacy by moving information off-chain, similar to Lightning Network. Chris suggests that even if only 5% of transactions were CoinSwaps, it would significantly improve users' privacy. He demonstrates how CoinSwaps can be used as payment and emphasizes that they are cheaper than Equal-Output CoinJoins. Chris concludes by noting that most day-to-day Bitcoin transactions are expected to happen off-chain using technologies like Lightning Network, which also enhances privacy.The email conversation also discusses the implementation of a new CoinSwap protocol. The protocol is split into phases: channel establishment, HTLC forwarding, HTLC resolution, and private key handover. The Spilman channel is used to create temporary unidirectional time-bound channels for simultaneous funding transactions without the risk of race loss. Bob has to wait for the incoming contract transaction before signing its outgoing contract transaction. The proposed alternative, swap-on-receive+swap-on-change, may not be suitable for every use case, but it is useful for day-to-day Bitcoin transactions.The concern over scalability and privacy in Bitcoin is discussed in a message from Lee Chiffre to Chris. Both Bitcoin and Monero face challenges related to large transaction sizes required for acceptable privacy. The proposed CoinSwap system aims to address these issues by enabling trustless coin swaps that are not linkable to the public blockchain. However, combining multi-transaction with routing may create scalability problems due to multiple branches and layers.In another message, ZmnSCPxj suggests using swap-on-pay or swap-on-receive+swap-on-change approaches for CoinSwap transactions. Swap-on-pay involves swapping funds before sending them to payees to prevent correlation between sends and receives. Swap-on-receive+swap-on-change involves maintaining two internal wallets, pre-mix, and post-mix wallets, to facilitate faster payments. It is noted that the swap-on-receive+swap-on-change approach may not be suitable for users who prioritize privacy and censorship resistance.The email exchange between Chris and ZmnSCPxj explores the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. The conversation also addresses scalability and privacy concerns in Bitcoin and discusses the implementation of a new CoinSwap protocol. The benefits of combining routing and multi-transaction techniques are examined, and various approaches for CoinSwap transactions are proposed.In a conversation about the CoinSwap protocol, it was noted that the order of funding transactions in a chained/routed swap could be used to derive the order of swaps, posing a security risk. To mitigate this, it is advisable for CoinSwap peers to wait for the counterparty's funding transaction to confirm before broadcasting their own. Additionally, the use of nLockTime-protected Backouts can allow unilateral recovery of funds if a funding transaction fails to confirm.The email discusses improvements to the CoinSwap protocol, including the use of nLockTime-protected Backouts and the creation of Spilman unidirectional payment channels to bring off-chain timing details out of sight. However, these approaches still have vulnerabilities that need to be addressed to prevent loss of control over coins.Security in cryptocurrency transactions is crucial, and waiting for funding transactions to confirm is recommended to avoid theft. Similar to Lightning Network, where contracts cannot be cancelled by publishing older states, the confirmation of the funding transaction in CoinSwap ensures that previous states cannot be validly spent. This highlights the importance of caution and patience when dealing with cryptocurrency transactions.The discussion between Chris and Ruben revolves around PayJoin-with-CoinSwap, which breaks the common-input-ownership heuristic and improves privacy. It can be useful for individuals recovering degraded privacy or spending from reused or linked addresses. However, there are downsides such as potential spying and the need for makers to reveal additional UTXOs. Using decoy UTXOs instead of PoDLE is suggested to resist attacks. Furthermore, the order of funding transactions for chained/routed swaps may