Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning a third time Chris,

Now unrelated to the funding order, but one of the reasons why timeliness is desirable for CoinSwap is that if possible, we want to ensure that sends from a user wallet are not correlatable with receives into that wallet.
Thus, there is the strong suggestion that before sending to a payee, the user wallet should swap, then use the swapped funds to pay the payee, i.e. swap-on-pay.
JoinMarket does this in `sendpayment.py`, for example, and this is the recommended way to perform payments out of the JoinMarket wallet.

Let me propose an alternative: swap-on-receive+swap-on-change.

ZeroLink already suggests that wallets maintain two internal wallets: a pre-mix wallet and a post-mix wallet.
With swap-on-receive, when the user wants a receive address, the wallet gets it from the pre-mix wallet address.
Then, when wallet notices any unspent funds on any pre-mix wallet address, the wallet automatically swaps it into the post-mix wallet.
This is swap-on-receive.
Long-term HODLing goes into post-mix wallet addresses.

Then, when sending, the wallet selects from the post-mix wallet coins, and spends those coins directly into the payee address.
If there is no exact amount, it has to have change.
The change output does *not* go to the pre-mix or post-mix wallet address.
Instead, it goes to a 2-of-2 funding outpoint for a new swap immediately.

This lets the payee receive its funds quickly, as soon as the transaction confirms, without waiting for the CoinSwap to complete.
Of course, the user now has to be online to *fully* receive funds (the user cannot spend the funds until it is in the post-mix wallet).

Regards,
ZmnSCPxj