waxwing @waxwing@x0f.org

(Just re reading my somewhat rushed prose, I would like to correct: "somewhat like creating a new account" should be "exactly functionally equivalent to creating a new account, unless there is a coding error (reused addresses)").

.. that like it or not, Joinmarket has never been something you can use in a simple way and expect defence against active attackers. I think a lot of people intuitively understand that, people who are deep into Bitcoin's mechanics. But a new or general user probably hasn't much of a clue.
While at the other end, at the level of persistent and intelligent use over time, even active attackers are going to really struggle. Mistakes have to be made. (6/6?)

#bitcoin #coinjoin

... our active attacker, notice that even when he succeeds in tieing groups of utxos to mixdepths, his success in maintaining ownership flows through future joins/transactions is contingent on this kind of break (a completion of a mixdepth closure) not occurring. Precisely when users switch to a taker role, that can happen (well, to be fair it can happen other ways such as just manually doing a sweep on your own with no coinjoin).

So overall, both the fee model and the active attack mean (5/n)

(see "Completed mixdepth closures" in https://github.com/AdamISZ/JMPrivacyAnalysis/blob/master/tumbler_privacy.md#joinmarket-wallet-closures for context).

People think change is toxic because it links across transactions. True, but a slightly different angle is to notice that sweeps create these "mixdepth closure completion" events that are almost like creating a new account/mixdepth.

And this is where the taker role comes back to prominence, as I mentioned in my analysis of the gridchain incident. Sweeps are a taker-side feature of #joinmarket .

To return to ... (4/n)

I emphasize *messy* - there are a bunch of difficulties in doing that, and it's very unreliable (how do you know that set (A, B, C) and set (D, E, F), which are not overlapping, are actually different mixdepths and not different subsets of 1? It's not impossible but can go wrong a ton of ways), but possible.

But here's the key: that links "sets of utxos in a mixdepth", even if successful, which is not *quite* the same as mixdepth(=account).What's the difference? Sweeps.

Clean your room! (3/n)

... then picking that maker explicitly (identified by pseudonym J5... - this is not perfectly reliable, but people do stay with one nym for a long while usually) in a sequence of coinjoin proposals, using up PoDLEs, but not *that* many, and deliberately choosing a bunch of different coinjoin amounts in the hope of getting them to spit out different sets of utxo inputs. It's messy, but you have a chance of picking up sets of utxos from different mixdepths, that you then know are linked .. (2/n)

This is probably a blog post of some sort, but I'm snowed under so just writing it here:

I think at a cursory glance, people overestimate Joinmarket's effectiveness, especially against *targeted* attacks, but if anything underestimate it when they take a deeper look.

Consider the idea of a targeted attack on a maker, identified e.g. through having done one coinjoin with them and knowing some utxos (say, just 1 for simplicity).

"Targeted" attack could just mean, acting as a taker, ... (1/n)

From my local orderbookwatcher this morning:

> 6 fidelity bonds found with 13.99603543 BTC total locked up

Well that escalated quickly (one day after the release).

(Sometimes you forget that there are users out there for whom 10 bitcoins is something you can lose down the side of the sofa)

#joinmarket

New release of Joinmarket.

Includes use of fidelity bonds (think: timelocked outputs acting as "skin in the game" to prevent Sybil attacks):

https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.0

Release notes give the necessary details as usual.

#bitcoin #joinmarket #coinjoin

Weird, 2 years after the static "pubkeys.txt" file that python.org hosted containing developers keys, was found to contain some fake keys, they finally merged a PR to remove that file from the web server:

https://github.com/python/pythondotorg/pull/1509

So this no longer resolves:
https://www.python.org/static/files/pubkeys.txt

It's on the internet archive though of course. Everything on the internet is forever.

If you're still using twitter, do you really think this is OK? Even if you're strongly in favour of vaccination, how can you live with a public forum that behaves this way? Remember they censored people suggesting the lab leak (and many, many other things ..):

https://www.zerohedge.com/political/shadow-state-twitter-suspends-commentator-criticizing-vaccine-policies

This is getting close to being as bad as what I thought was the *worst* aspect of the CCP's regime in China - complete speech control.

New paper with a survey of privacy ("mixing"; not the best term, but oh well) techniques used in Bitcoin, it looks at first glance to be worth some reading. Includes a lot of lesser known techniques. In particular, includes several that were never really implemented (including stuff on my blog like CoinjoinXT), so in that sense it's unusually thorough.

https://eprint.iacr.org/2021/629

#bitcoin #coinjoin #privacy

https://www.youtube.com/watch?v=jpsGLsaZKS0