undeath

Fair point on the sybil attack on Directory Servers. However, I am strongly opposed to having a hand-picked list of trusted Directory Servers. It adds centralization, both in the servers...

> Directory Servers would be run by volunteers. Having makers host their own offers would cost them more resources, but they earn an income from their activities and takers also...

> Market-makers-as-transport-peers have an incentive to censor their competitors offers, in the directory servers setup they also have an incentive to not gossip the peering information, because that can limit...

A summary of the IRC log @chris-belcher linked above: a draft for a protocol that is easy enough to implement/deploy while offering a reasonable improvement over the current IRC protocol....

I think it's a really interesting idea. It would need some sensible upper limit for change addresses, maybe 4 or 5. Where it becomes tricky is when thinking about the...

What are the advantages of snap over the docker images we already have? I guess Qt support? Other than that I second @kristapsk idea about having a `contrib/` dir.

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...

Isn't the current behaviour correct? Assume a single jmdaemon is used by multiple clients, they all will require different nicks and thus different connections.

FBs are used to sign a maker's offers (edit: offers is not quite correct, actually it's just their nickname), not their UTXOs. Randomized nicks indeed are not helpful with FBs.

You are confusing two things: the coinjoin input UTXOs and the FB UTXO. The FB UTXO is not part of the coinjoin transaction.