Is this a spam attack?

[wazint]

I'm running the yg-privacyenhanced.py script. For the last day or so I've been seeing a lot of entries like the below in my logs.

2023-09-14 15:36:22,157 [INFO]  filling offer, mixdepth=1, amount=122514..
2023-09-14 15:36:22,175 [INFO]  sending output to address=bc1...
2023-09-14 15:45:27,280 [INFO]  filling offer, mixdepth=2, amount=626122..
2023-09-14 15:45:27,297 [INFO]  sending output to address=bc1...

I've had around 1000 of these, but only 1 or 2 actual transactions.

This "uses up" addresses, meaning the gap limit on my watch wallet needs to be set higher and higher. I'm also concerned it could be an attempt to identify makers?

Edit / update

Thanks for the quick replies!

Over about 17.5 hours:

• 71 occurrences with amounts ranging from 1054593 to 65053791 (not far away from my min and max at the time)
• 17 blacklisted commitments (all unique)

OK, so a slight exaggeration :)
It showed no sign of stopping the the time I terminated the script.

Value of occurrences in time order

In ascending order

[kristapsk]

I'm also concerned it could be an attempt to identify makers?

It could be. But such an attack isn't free, it costs attacker money. To initiate coinjoin attempt, with default settings taker must have at least 20% of amount (taker_utxo_amtpercent) as P(o)ODLE commitment and it's allowed to re-use same commitment up to three times (taker_utxo_retries), then it is banned and attacker needs to provide new UTXO commitment, which means creating new Bitcoin transactions and paying tx fee.

[wazint]

Thanks! I've updated the question with more info

with default settings taker must

Are these settings an attacker (taker) can change in their configuration, or on my (maker) side?

[PulpCattel]

It's on your side, see in your settings the ANTI-SNOOPING section (read the comments there). The taker sends you the commitment and you decide if you are okay with it or not, there should be nothing the attacker can do about this.

If you feel under attack, you can change these settings to be more strict and make the attack more expensive, but note at least two side-effects:

• You might restrict honest takers too (e.g., their internet dies during CoinJoin negotiation and you won't accept their commitment a second time. Note, the other makers with default values will, so possibly the CoinJoin will go through without you.) So, whether this is worth it or not will depend on your situation.
• If you switch to the taker role yourself, these settings will impact you too, meaning that locally your taker will assume these are the settings he has to respect to please makers. I.e., you probably want to revert these settings if you switch role.

[AdamISZ]

Imo, realistically, we can't recommend people to change these settings. As it says in the comments (something like) "DO NOT EDIT THIS!" (unless you know exactly what you're doing).

I regretted putting those values in the config file at all, it's really quite a sticky consensus thing. I can see from your comment @PulpCattel that you fully understand this, but it will be way over most users' heads.

(
For clarity for any reader that doesn't quite get the dynamic: Suppose there are 10 makers and you change your anti-snoop settings to be more strict. And a taker comes along with consensus settings, his podle commitment matches the criteria of all other 9, but not yours, and he's asking for 10 makers. Then he fails and uses up that commitment. To be clear, it's things like this that make "fallback to less than requested makers" (e.g. you asked for 10 makers but you'll still do a coinjoin if at least 5 of them cooperate) so critical for JM to work. But the principle is clear: we really want everyone to stick to defaults, for this.
)

[PulpCattel]

This subject reminds me a lot of Bitcoin Core policies (and in part of fidelity bonds settings), and I think I'd make similar arguments. As much as I can understand your point, I ultimately think you did good putting those values in the config. For these settings in particular, it seems logical that different users might very well have a different tolerance, even if we'd really like everybody to be on the same page.

Maybe this tolerance should be advertised by the maker, so that the taker doesn't even try (similar to how we could do with the tx feerate), but that looks like a big can of worms that we don't have to open here.

Point taken tho that we should at least be very careful how and to whom we suggest this option.

[PulpCattel]

+1 what kristapsk said.

Could you provide "exact" (if you don't want to reveal the precise number, at least an indicative range) quantification of this? Is 1000 actually it or did you just mean "a bunch"? What's the bitcoin amount of these requests? Are they all sub 1kk sats? Are they close to your max amount offered? Are they all similar or wildly different? etc.

At least a few people complained about this also on telegram, but IIRC in their case it mostly didn't go this far (i.e., up to the filling offer part) but was more about "commitment blacklisted."

[wazint]

Thanks, I've updated the question with more info.

I have noticed "lots" of "commitment blacklisted" log entries in the past. While I've never been comfortable about it, reading up on P(o)ODLE commitments and seeing a few references to similar behaviour put my mind somewhat at ease.

[PulpCattel]

Thank you for the data. It does look suspicious, at least a little bit.
Further reading if you want to go down this rabbit hole:

• Bad faith taker spy not filling orders so that it learns which UTXOs belong to which maker, allowing future unmixing joinmarket#156 (note: this is from the old JoinMarket repo)
• https://reyify.com/blog/racing-against-snoopers-in-joinmarket-0.2
• Taker-side sybil attack #960

And yes, in case of commitment blacklisted your maker bot will immediately stop answering, so the attacker (or just a taker with a messed up config file or something) doesn't learn anything.

[wazint]

Thanks. I've read through those threads.

Of those offers made and not completed, most were mix depth 0 and 1. By using different amounts, they could have been able to determine most/all of my UTXOs at those depths, right?

And they can tie this information to my fidelity bond? So could pick up where they left off if I simply restarted.

I don't know the finer details of the protocol (and can't seem to find docs on that?), but if I understand correctly, with the default settings, an attacker can learn of up to 3 UTXOs for each UTXO they commit before it gets blacklisted. Which UTXOs they learn about probably depends on the relative size of UTXOs. For a maker with relatively low liquidity offered, it would not require much capital (in UTXOs, which can be unlocked/re-used) or cost in network fees (a few $ to create ~100 UTXOs?) for a malicious taker to catalogue the maker's UTXOs?

Ultimately I'm trying to determine what information I may have leaked, what the consequences of that could be, and what I can do to mitigate those consequences.

Then I'm also trying to better understand the limitations of privacy preservation for makers on JoinMarket, and maybe try and help improve it.

Lots of questions! Sorry :)

[AdamISZ]

Yes, there's some non-trivial subtlety in the answer to "what information leaks if someone really tries their best to snoop me?". Essentially, they will be getting groups of utxos, all from the same mixdepth, and, with enough variation in the amount requested, it's at least reasonable to assume they might be able to get a full list of the utxos in that specific mixdepth.

Consider, however: if you do a sweep out of that mixdepth (spending all of it), either by doing a taker-side coinjoin yourself, or by doing a simple non-coinjoin spend, then you are going to reveal the same information.

Notice that it is very hard for them to get complete info about all mixdepths (probably impossible in most cases). Most of the time you have a big chunk of coins in a single mixdepth (concentration algorithm, more on that below).

The basic principle at work is: coins in one mixdepth (or account, or pocket) can all be co-spent, so you never have any expectation that they are somehow unlinked. They might not be publically linked, due to the exact pattern of co-spending, but you never have a guarantee of that, and it's generally not true. The only thing that is guaranteed is, if you ever sweep that mixdepth (spend all coins in it), then it is effectively wiping the slate clean, and it's really a "new" mixdepth now.

So, are we going to use more than one mixdepth, depending on offer size? The answer is yes in the general case, but afaict more than 2 is unlikely, this is because of the "clumping" effect of the algorithm we use. See the comments on this rather complicated algorithm here:

joinmarket-clientserver/scripts/yg-privacyenhanced.py

Lines 25 to 30 in a6b13c2

	"""Mixdepths are in cyclic order and we select the mixdepth to
	maximize the largest interval of non-available mixdepths by choosing
	the first mixdepth available after the largest such interval.
	This forces the biggest UTXOs to stay in a bulk of few mixdepths so
	that the maker can always maximize the size of his orders even when
	some coins are sent from the last to the first mixdepth"""

In that context, these attacks can certainly be effective against Joinmarket as a whole, if they manage to capture enough state of enough makers that, looking at a coinjoin, they can retroactively find out which makers are which coinjoin outputs, and find the taker by a process of elimination. But, as an attack on a specific maker's privacy, it's less severe, I think. But, still, a concern.

I don't know if your data shows a clear example of such an attack. Quite possibly. You do, correctly, observe that the cost of such attacks is extremely low if we think about just doing it to a few makers, at a slow speed. But making the cost high would make the system very difficult for takers to use, indeed.

It's also interesting to observe that such an attacker is leaking their own utxos.

[AdamISZ]

Another thing to bear in mind is that this is very much a maker side thing; a maker always leaks their coinjoin-outs to the taker, and can never remove change outputs (which have the unfortunate tendency to link utxos in the mixdepth over time) from their coinjoins. So from a privacy perspective it's much better to do taker sweeps really, though we have tended to advise mixing roles as best (nothing is certain, but it does seem reasonable).