'max_mix_depth' setting still supported/recommended?

[xanoni]

I saw that the QT guide references the max_mix_depth setting. When I grep the code, I can't find any other user-facing mentions of this setting. I also couldn't find it in the auto-generated joinmarket.cfg. Can this setting be safely increased, or would it result in any unwanted behavior and running a second wallet is advised instead?

$ grep -iEIr '(max_mix_depth|options\.mixdepth)' ./joinmarket-clientserver.git

./tumbler.py:    max_mix_depth = options['mixdepthsrc'] + options['mixdepthcount']
./tumbler.py:    if options['amtmixdepths'] > max_mix_depth:
./tumbler.py:        max_mix_depth = options['amtmixdepths']
./tumbler.py:    wallet = open_test_wallet_maybe(wallet_path, wallet_name, max_mix_depth, wallet_password_stdin=options_org.wallet_password_stdin)
./tumbler.py:                            max_mix_depth)
./qtsupport.py:                'max_mix_depth': int,
./qtsupport.py:    'max_mix_depth': 'Total number of mixdepths in the wallet, default 5',
./qtsupport.py:        sMM = [(0, jm_single().config.getint("GUI", "max_mix_depth") - 1), (3, 20),
./snicker/snicker-recovery.py:    max_mix_depth = max([options.mixdepth, options.amtmixdepths - 1])
./snicker/snicker-recovery.py:        wallet_path, wallet_name, max_mix_depth,
./snicker/receive-snicker.py:    max_mix_depth = max([options.mixdepth, options.amtmixdepths - 1])
./snicker/receive-snicker.py:        wallet_path, wallet_name, max_mix_depth,
./snicker/snicker-seed-tx.py:    max_mix_depth = max([options.mixdepth, options.amtmixdepths - 1])
./snicker/snicker-seed-tx.py:        wallet_path, wallet_name, max_mix_depth,
./snicker/snicker-seed-tx.py:    utxo_dict = wallet_service.get_utxos_by_mixdepth()[options.mixdepth]
./snicker/snicker-seed-tx.py:        wallet_service.get_new_script(options.mixdepth, 1)) for _ in range(3))
./snicker/create-snicker-proposal.py:    max_mix_depth = max([options.mixdepth, options.amtmixdepths - 1])
./snicker/create-snicker-proposal.py:            wallet_path, wallet_name, max_mix_depth,
./snicker/create-snicker-proposal.py:    prop_utxo_dict = wallet_service.select_utxos(options.mixdepth,
./snicker/create-snicker-proposal.py:        options.mixdepth + 1) % (wallet_service.mixdepth + 1), 1)
./snicker/create-snicker-proposal.py:    change_spk = wallet_service.get_new_script(options.mixdepth, 1)
./sendpayment.py:        mixdepth = options.mixdepth
./sendpayment.py:        schedule = [[options.mixdepth, amount, options.makercount,
./sendpayment.py:    max_mix_depth = max([mixdepth, options.amtmixdepths - 1])
./sendpayment.py:        wallet_path, wallet_name, max_mix_depth,
./sendpayment.py:            total_cj_amount = wallet_service.get_balance_by_mixdepth()[options.mixdepth]
./sendpayment.py:        manager = parse_payjoin_setup(args[1], wallet_service, options.mixdepth)
./joinmarket-qt.py:                        'max_mix_depth', 'order_wait_time', 'checktx']
./joinmarket-qt.py:        if required_mixdepths > jm_single().config.getint("GUI", "max_mix_depth"):
./joinmarket-qt.py:            jm_single().config.set("GUI", "max_mix_depth", str(required_mixdepths))
./joinmarket-qt.py:            0, jm_single().config.getint("GUI", "max_mix_depth") - 1))
./joinmarket-qt.py:        for i in range(jm_single().config.getint("GUI", "max_mix_depth")):
./joinmarket-qt.py:        for i in range(jm_single().config.getint("GUI", "max_mix_depth")):
./joinmarket-qt.py:        nm = jm_single().config.getint("GUI", "max_mix_depth")
./receive-payjoin.py:    max_mix_depth = max([options.mixdepth, options.amtmixdepths - 1])
./receive-payjoin.py:        wallet_path, wallet_name, max_mix_depth,
./receive-payjoin.py:    if wallet_service.get_balance_by_mixdepth(minconfs=1)[options.mixdepth] == 0:
./receive-payjoin.py:            options.mixdepth) + ", no confirmed coins. Shutting down.")
./receive-payjoin.py:    receiver_manager = JMBIP78ReceiverManager(wallet_service, options.mixdepth,

[undeath]

If specified, the maximum mixdepth is set upon opening a walltet using the -m/--mixdepth option, or else inferred from the wallet file. The max_mix_depth setting seems to be the corresponding Qt equivalent for the cli option. I could be wrong though. Not very familiar with the Qt code.

[xanoni]

-m/--mixdepth

You're right. I didn't realize that it had a different name in the CLI. Maybe a point can be made for harmonizing it?

[xanoni]

$ grep -iIEr '(-+[a-z]*_?mix_?depth)' .

./docs/release-notes/release-notes-0.8.2.md:### Add per-mixdepth view for wallet-tool
./docs/NATIVE-SEGWIT-UPGRADE.md:* Move funds into it, like any new wallet; if you are moving from an old Joinmarket wallet to this new one, I suggest doing sweeps per-mixdepth, but (a) you can use coin-freezing to use individual coins and not connect them, if you prefer, (b) using a coinjoin on the *old* Joinmarket pit to do the transfer may not make much sense, since the output address will be 'bc1' not '3' and so the anon set effect will be lost.
./jmclient/test/test_taker.py:        # parameters such that our in-mixdepth utxos are not good
./jmclient/jmclient/wallet_utils.py:                      '--mixdepth',
./jmclient/jmclient/cli_options.py:            '--mixdepthsource',
./jmclient/jmclient/cli_options.py:            '--mixdepthcount',
./jmclient/jmclient/cli_options.py:            '--amtmixdepths',
./jmclient/jmclient/cli_options.py:                      '--mixdepth',
./jmclient/jmclient/cli_options.py:                      '--amtmixdepths',
./jmclient/jmclient/yieldgenerator.py:    parser.add_option('-m', '--mixdepth', action='store', type='int',
./scripts/snicker/snicker-recovery.py:    parser.add_option('-m', '--mixdepth', action='store', type='int',
./scripts/snicker/snicker-recovery.py:                      '--amtmixdepths',
./scripts/snicker/receive-snicker.py:    parser.add_option('-m', '--mixdepth', action='store', type='int',
./scripts/snicker/receive-snicker.py:                      '--amtmixdepths',
./scripts/snicker/snicker-seed-tx.py:                      '--mixdepth',
./scripts/snicker/snicker-seed-tx.py:                      '--amtmixdepths',
./scripts/snicker/create-snicker-proposal.py:          '--mixdepth',
./scripts/snicker/create-snicker-proposal.py:                      '--amtmixdepths',
./scripts/joinmarket-qt.py:    sub-objects to arrange the per-mixdepth and per-address lists.
./scripts/add-utxo.py:        '--max-mixdepth',
./scripts/receive-payjoin.py:    parser.add_option('-m', '--mixdepth', action='store', type='int',
./scripts/receive-payjoin.py:                      '--amtmixdepths',

Seems there are a few different variations... I also see --max-mixdepth.

[kristapsk]

Renaming CLI options would be bad, as it breaks backwards compatibility, people might be calling them automatically from different custom scripts.

[xanoni]

I was thinking about (a) accepting all commonly used versions or (b) changing it in the GUI.

[xanoni]

(I can create a PR with something that would make sense to me ... unless you know that you want to leave everything as is ... let me know)

[AdamISZ]

I know this is a late response but I do want to say: I believe this certainly needs a review/rationalization as several changes happened over several years in a piecemeal fashion.

I believe what made this difficult was the concept of "wallet with a certain number of accounts, that a user may want to dynamically resize (i.e. more accounts)", which is mostly but not exclusively related to the use of the tumbler algorithm.

Because it got complicated, I have tended to want to tell users "please just stick with 5 accounts" - for the sake of my/our sanity if nothing else. However that's not a concept that others have run with. And many people seem to like the idea of "lots of mixdepths" (they're not wrong, but they often misinterpret that "number of joins" is directly related to number of mixdepths, and that there is an actual sense of "depth", which there isn't, it's a poor name).

[xanoni]

(they're not wrong, but they often misinterpret that "number of joins" is directly related to number of mixdepths, and that there is an actual sense of "depth", which there isn't, it's a poor name).

@AdamISZ Yeah I agree. When I first heard about mixdepths, I assumed that there was a qualitative difference between them (higher=better) and that coinjoins would be priced differently depending on what mixdepth the maker coins came from. Obviously, this is not the case.

(i.e. more accounts)

It could also be the opposite, i.e., users starting with too many accounts and then always using the --max-mixdepths setting to limit the depths actually used. This could be beneficial for makers, given fewer accounts = higher average balance per account = probably more coinjoin rounds participated in.

[AdamISZ]

After #1324 we now have basically deprecated using more than the default 5 mixdepths, see:

https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1324/files#diff-f91f4943ccbebe2fdab46ec3bb551113749edc870f2330850320dacaac2dc216R43-L43

so closing.