<waxwing> another thought i had, which i forgot to mention: a significant problem with joinmarket (as an idea generally, not just the implementation we have) is: directly spending in a single coinjoin is hampered by fees.
<waxwing> i mean this specifically: one privacy gain of coinjoin can be: paying someone reveals your own coins. this is not true in abstract in coinjoin because the payment is delinked from the specific set of inputs.
<waxwing> however this is not true in a JM CJ *if* we can assume positive fees paid by the spender.
<waxwing> hence, it is worth observing that the zero-fee-offer maker, or the negative-fee-offer maker, can remove that problem.
<waxwing> which opens up the possibility of suggesting to people that if they want to run a maker for privacy, they could specifically choose to offer zero fees and some reasonable fraction of bitcoin-cj-fee
<waxwing> or also negative fees (although be careful!)
<waxwing> this is, of course, a very similar but also slightly different suggestion to doing a patientsendpayment idea. one important functional difference is that there is a class of payments where you can't afford to be patient (most, in fact)
<waxwing> it's also nice that this can be done without software changes. just a case of people choosing to offer it, and takers consciously deciding to use it; they may choose low numbers of counterparties for this purpose (or just pick 1 or 2)