Configuring with joinmarket.cfg

The joinmarket.cfg file looks like this. Lines starting with # are comments

[BLOCKCHAIN]
blockchain_source = blockr
#options: blockr, bitcoin-rpc, regtest
# for instructions on bitcoin-rpc read
# https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node
network = mainnet
rpc_host = localhost
rpc_port = 8332
rpc_user = bitcoin
rpc_password = password

[MESSAGING]
host = irc.cyberguerrilla.org
channel = joinmarket-pit
port = 6697
usessl = true
socks5 = false
socks5_host = localhost
socks5_port = 9050
#for tor
#host = 6dvj6v5imhny3anf.onion
#onion / i2p have their own ports on CGAN
#port = 6698
#usessl = true
#socks5 = true

[TIMEOUT]
maker_timeout_sec = 30
unconfirm_timeout_sec = 90
confirm_timeout_hours = 6

[POLICY]
# for dust sweeping, try merge_algorithm = gradual
# for more rapid dust sweeping, try merge_algorithm = greedy
# for most rapid dust sweeping, try merge_algorithm = greediest
# but don't forget to bump your miner fees!
merge_algorithm = default
# the fee estimate is based on a projection of how many satoshis
# per kB are needed to get in one of the next N blocks, N set here
# as the value of 'tx_fees'. This estimate is high if you set N=1, 
# so we choose N=3 for a more reasonable figure,
# as our default. Note that for clients not using a local blockchain
# instance, we retrieve an estimate from the API at blockcypher.com, currently.
tx_fees = 3
# For users getting transaction fee estimates over an API
# (currently blockcypher, could be others), place a sanity
# check limit on the satoshis-per-kB to be paid. This limit
# is also applied to users using Core, even though Core has its
# own sanity check limit, which is currently 1,000,000 satoshis.
absurd_fee_per_kb = 150000
# the range of confirmations passed to the `listunspent` bitcoind RPC call
# 1st value is the inclusive minimum, defaults to one confirmation
# 2nd value is the exclusive maximum, defaults to most-positive-bignum (Google Me!)
# leaving it unset or empty defers to bitcoind's default values, ie [1, 9999999]
#listunspent_args = []
# that's what you should do, unless you have a specific reason, eg:
#  !!! WARNING !!! CONFIGURING THIS WHILE TAKING LIQUIDITY FROM
#  !!! WARNING !!! THE PUBLIC ORDERBOOK LEAKS YOUR INPUT MERGES
#  spend from unconfirmed transactions:  listunspent_args = [0]
# display only unconfirmed transactions: listunspent_args = [0, 1]
# defend against small reorganizations:  listunspent_args = [3]
#   who is at risk of reorganization?:   listunspent_args = [0, 2]
# NB: using 0 for the 1st value with scripts other than wallet-tool could cause
# spends from unconfirmed inputs, which may then get malleated or double-spent!
# other counterparties are likely to reject unconfirmed inputs... don't do it.

#options: self, random-peer, not-self, random-maker
# self = broadcast transaction with your own ip
# random-peer = everyone who took part in the coinjoin has a chance of broadcasting
# not-self = never broadcast with your own ip
# random-maker = every peer on joinmarket has a chance of broadcasting, including yourself
tx_broadcast = self

#THE FOLLOWING SETTINGS ARE REQUIRED TO DEFEND AGAINST SNOOPERS.
#DON'T ALTER THEM UNLESS YOU UNDERSTAND THE IMPLICATIONS.

# number of retries allowed for a specific utxo, to prevent DOS/snooping.
# Lower settings make snooping more expensive, but also prevent honest users
# from retrying if an error occurs.
taker_utxo_retries = 3

# number of confirmations required for the commitment utxo mentioned above.
# this effectively rate-limits a snooper.
taker_utxo_age = 5

# percentage of coinjoin amount that the commitment utxo must have
# as a minimum BTC amount. Thus 20 means a 1BTC coinjoin requires the
# utxo to be at least 0.2 btc.
taker_utxo_amtpercent = 20

#Set to 1 to accept broadcast PoDLE commitments from other bots, and
#add them to your blacklist (only relevant for Makers).
#There is no way to spoof these values, so the only "risk" is that
#someone fills your blacklist file with a lot of data.
accept_commitment_broadcasts = 1

#Location of your commitments.json file (stores commitments you've used
#and those you want to use in future), relative to root joinmarket directory.
commit_file_location = cmttools/commitments.json

It has simple options for changing the bitcoin network, blockchain source and irc options.

Network can be mainnet or testnet

When setting blockchain_source to bitcoin-rpc and using the rpc options, read this: See also: https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node

Locations of joinmarket.cfg, wallet file(s) and paths from which to execute JoinMarket scripts

A default joinmarket.cfg is created on on install in JoinMarket directory. JoinMarket scripts should be executed from the same location. For example, to show your default wallet's seed using wallet-tool.py, first change to JoinMarket directory where the script is located and then execute it like so:

python wallet-tool.py wallet.json showseed

Tips:

• If joinmarket.cfg is removed from JoinMarket directory, a default joinmarket.cfg will be re-created on first run (from this directory) with a valid wallet file.
• When you execute wallet-tool.py from directory where this script is located, it will search for the wallet file in wallets subdirectory where ${YOUR-WALLET-NAME}.json can be found.
• Running JoinMarket scripts from other locations may result in unpredictable behavior (such as errors).

Connecting with Tor

You need Tor running locally. Change the host field to the cyberguerrilla onion, enable socks5 and ssl.

Input Merging Policy

By default JoinMarket bots will choose transaction inputs that maximize your privacy. It will usually will avoid combining many inputs together which provides evidence of common ownership. The downside is that this will produce lots of small-value UTXOs. They will not be dust because they are larger than DUST_THRESHOLD but some people find them annoying. If this bothers you, the following values are available for the merge_algorithm parameter:

• default: This algorithm (enabled by default) will spend from a single input whenever possible. The only situation that causes it to merge inputs is when there are no inputs larger than the coinjoin size.
• gradual: This algorithm will merge the shortest run of consecutive outputs smaller than, but summing to more than, the coinjoin size. If all the outputs less than the coinjoin size summed together are still insufficient, then a single larger output will be used.
• greedy: This algorithm is similar to gradual, but prefers to take larger numbers of smaller inputs, and is able to use a non-consecutive set. It will never include an input which could be removed without remaining above the coinjoin size, but could still select a larger number of inputs than gradual.
• greediest: This algorithm will take the shortest run of consecutive inputs, starting from the smallest, which sum to more than the coinjoin size. This will often result in extraneous inputs, but can clean the dustiest of wallets within a couple of transactions. Extraneous inputs means larger transactions, which could take longer to confirm. This algorithm is not recommended for continuous use, but rather for one-shot use; an alternative approach is to use the "sweep" mode of sendpayment.py.

For privacy concerns, none of these options will ever combine coins belonging to separate mixdepths. In other words, JoinMarket will first select a mixdepth for the transaction, and only then run the configured selection algorithm on the unspent coins within that mixdepth alone.

Anti-snooping options

The set of options at the end of the POLICY section are to support the "commitments" of utxos using PoDLE. It is best not to change these at all. More information can be found here and here for more details.