Configurable mixdepths

[AdamISZ]

Code currently hardcodes mixdepth 0 as funding depth and mixdepth 1 as destination. It's nice to have a simple default for easier configuration, but e.g. people with existing joinmarket wallets would like to be able to use different mixdepths for the inbound and outbound.

A very braindead simple first step is to add source_mixdepth and destination_mixdepth in the config so they can be different numbers, even if the model is unchanged. Note that this would have implications for wallet load/sync (currently using 3 in the code).

Related: backout is currently using the same outbound mixdepth, although I originally intended to have it be a third mixdepth (hence the default wallet is 3 mixdepths).

Related: the server may have special considerations here. There might be a good case for having multiple separate mixdepths to serve utxos from, like multiple streams. Not at all sure.

Not currently sure exactly what to do about this, but it should be revisited.

[chris-belcher]

The point of mixdepths for coinjoins is they prevent the situation where the coinjoin output and change output are recombined in the same transaction, which would result in coinjoins being unmixed.

For coinswap I think mixdepths aren't required at all.

[AdamISZ]

I don't understand that. If I have a wallet with 5 utxos, and suppose that common ownership is already known, and I "swap" 2 of them into new utxos, I don't want the new, swapped utxos to be reused with the 3 that were left over, as common ownership would be established again.

[chris-belcher]

Yes you're right if common ownership is already known. (For example if you gave 5 deposit addresses to someone to pay you, and they paid you with 5 transactions) then you want the coinswap destination to be another mixdepth. So yes takers will require more than one mixdepth if they're doing repeated coinswaps.

But I think mixdepths won't be needed for makers as long as addresses are not reused and it's unknown which output is the change output. (I'll need to read again exactly how closure analysis works to make double sure of this).

The reason it's different for coinjoins is that the change output is always obvious.

But for now there's no harm in having two mixdepths for makers as well.

[AdamISZ]

Yes it remains somewhat of an open question (I also need to think more about it), and good point mentioning change addresses, e.g. #17 . Also the latest thoughts I was writing out in #8 may involve extra outs in the backouts. My first thought was 3 "pockets"/"accounts" (need to stop calling them mixdepths here perhaps) so that the backouts were isolated. In any case, this is definitely something to come back to.

[AdamISZ]

As of cd39b5cbb8af02d3df96c2911d5c37596185e876 , the new approach to fees, the situation is:

Account 0 is used for funding and for all returning payments except the "proper" coinswap output (the one coming from TX4/TX5, i.e. successful), which goes to account 1 (unless the user specifies that as an external address (different wallet of their own, or payment to a 3rd party)). This means that the user is protected from re-combining the coinswapped utxo with the non-coinswapped ones. And any backout, although technically it may still be a coinswap (example: Alice redeems the backout via TX3, which means the coins come from Carol), it is treated as not such based on the fact that its coinswappy nature is transparent :) This point is of course debatable, but it seems the most conservative approach (only a "proper" TX4/TX5 output has the full mixing/delinking/anonymity set properties we're trying to achieve).